RE: [Xen-devel] MSI-X interrupts to guests

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

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