Thanks for the discussion! I will firstly use Keir's suggestion to let Xen to
allocate the pirq.
Another point is, should we export vector to domain0/driver domain in long run?
I think vector is an item for cpu, so that when interrupt happen, cpu will jump
to IDT entry index by the vector. But for dom0/domU, it has no idea of IDT at
all, so why should we export vector for domain0/domU? Is the pirq enough?
As for irq/pirq, I think irq is the index to irq_desc( stated at
http://www.webservertalk.com/archive242-2006-5-1471415.html and
http://marc.info/?l=linux-kernel&m=110021870415938&w=2), while pirq is a
virtual interrupt number (something like gsi) injected by xen and is
corresponding to physical interrupt source. What's special in domain0/domain U
is, in normal kernel, the gsi/irq maybe different, while in domain0/domainU, we
can arrange special so that irq/pirq is the same.
With this, for IOAPIC, domain0 will get a pirq from xen for a specific physical
gsi,and then in io_apic_set_pci_routing(), the irq, instead of vector will be
used. For msi(x), the physdev_msi_format() will pass pirq/domain pair, and xen
will return back content with vector information in it.
Not sure if my understanding is right. Also, I suspect even my understanding is
right, should we do like this, since this will cause a lot of changes to
ioapic-xen.c code (we may have less changes after domain0 switch to latest
kernel).
Thanks
Yunhong Jiang
-----Original Message-----
From: Tian, Kevin
Sent: 2007年5月28日 20:54
To: 'Keir Fraser'; Jiang, Yunhong; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] [PATCH 2/3][RFC] MSI/MSI-X support fordom0/driver
domain
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年5月28日 20:41
>
>On 28/5/07 13:29, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> I understand your point, and yes that's an easy implementation. My
>> small concern now is just whether it's worthy to pull Xen into resource
>> allocation for which Xen has nothing reference at all. Shouldn't the
>> components to assign device irq better does the allocation based on
>> its own policy? For current stage, HVM domain has device model to
>> provide 'pirq' layout and driver domainU has pciback. Even when later
>> there're other places to assign device irqs, I think it's still
>> responsibility
>> of that place to construct the pirq name space for domU. For example,
>> how about the simple Xen pirq allocation policy doesn't satisfy the
>> special requirement of that place, like a special prime-number style
>> (just kidding)? If such simple, but no-use from Xen POV, interface
>> doesn't have users now and also may not address all possibilities in
>> the future, do we need that indeed?
>
>You may be right. I just like to keep the hypervisor interfaces as flexible
>as possible, to avoid unnecessarily baking in assumptions based on their
>initial usage. It's a pretty small issue actually, since we can get the same
>behaviour by dom0 attempting to map onto pirqs from zero upwards until
>it
>finds one that isn't already in use.
>
> -- Keir
Yep, exactly a small issue. Let's expect Yunhong's next version after
incorporating your comments. :-)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home