| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] MSI-X interrupts to guests
>>> Kieran Mansley <kmansley@xxxxxxxxxxxxxx> 16.04.09 17:47 >>>
>On Thu, 2009-04-16 at 16:39 +0100, Espen Skoglund wrote:
>> > 2a) Attempt to map this to the guest using PHYSDEVOP_map_pirq with
>> > parameters:
>> > map_irq.domid = guest_domid;
>> > map_irq.type = MAP_PIRQ_TYPE_GSI;
>> > map_irq.index = vector;
>> > map_irq.pirq = -1;
>>
>> > => gives an error in the hypervisor:
>> > (XEN) physdev.c:61: dom1: map invalid irq 510
>>
>> IRQ510? This definitely sounds wrong. This can't possibly be the
>> "PIRQ" assigned to the MSI vector.
>
>It's not - it's the vector itself. Sadly the code in question (msi-
>xen.c) seems to confuse the use of pirq and vector in the variable
>names, so I'm not exactly sure how to describe it. It's the returned
>value from msi_map_vector() when called by pci_enable_msix() in dom0.
No, there simply cannot be a vector 510 - x86 is limited to 256 vectors. What
you get back here is a (Xen) IRQ number. The question is why this is outside
the default NR_IRQS range - are you building Xen with support for more than
256 IRQs? See get_free_pirq(), which starts its iteration ar NR_IRQS-1 for
the case you're interested in. Or is 510 perhaps a Linux IRQ number rather
than a Xen one?
PHYSDEVOP_map_pirq also returns vector information, but I strongly believe
this is actually a mistake, as no guest should ever care about the vector Xen
uses for a particular interrupt.
>What is the magic step I'm missing to go from the vector that I get back
>from pci_enable_msix() to the value for "PIRQ assigned to the MSI
>vector" to give to PHYSDEVOP_map_pirq?
I would think your problems begin with msi_map_pirq_to_vector() not having
a way to know that the particular IRQ is to not go to Dom0, but to a DomU:
msi_get_dev_owner() only considers the whole device. You may need to
somehow undo this for those IRQs that you want to pass through (since
you want the Xen PIRQ number here in order to pass to the DomU, not the
Linux one). Whether not undoing the whole operation, but instead just
obtaining the Xen PIRQ number would work I'm not really certain, but would
assume that would at least have the unintended side effect of sharing the
IRQ between DomU and Dom0.
Otoh - did you check whether the VMDQ and/or SR-IOV work already
contains a solution to your problem? I didn't look closely at that code yet,
but would suppose that there passing through IRQs without the whole
devices should also be used in some way.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home