This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>, Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] MSI-X interrupts to guests
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Mon, 20 Apr 2009 17:47:58 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 20 Apr 2009 02:49:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49EC5675.76EA.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1239810184.4306.38.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18918.1125.161033.236856@xxxxxxxxxxxxxxxxxx> <18918.1787.569721.715154@xxxxxxxxxxxxxxxxxx> <1239812710.4306.48.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18918.3011.32917.886597@xxxxxxxxxxxxxxxxxx> <1239895162.4289.52.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18919.20809.69840.702986@xxxxxxxxxxxxxxxxxx> <1239896870.4289.60.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <49EC5675.76EA.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcnBlrSouSALhZpSTp6NExyQQ1h+NwAA1bVg
Thread-topic: [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

<Prev in Thread] Current Thread [Next in Thread>