| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] MSI-X interrupts to guests
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote:
>>>> 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
One tricky thing here is we can't change the definition of msix_entry. BTW, the
msi_map_vector() is a bit confusing.
>> 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.
Agree, this should be wrong. Guest should have no idea of vector. Not sure if
there are any special reason for it.
>
>> 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.
I suspect SR-IOV will have no such usage model, since in SR-IOV will have
different VF for guest. No idea of VMDq.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home