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] Re: APIC rework

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: RE: [Xen-devel] Re: APIC rework
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Wed, 25 Nov 2009 23:21:45 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Fraser <keir.fraser@xxxxxxxxxxxxx>, Keir
Delivery-date: Wed, 25 Nov 2009 07:22:23 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091125134144.GA2586@xxxxxxxxxxxxxxxxxxx>
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: <706158FABBBA044BAD4FE898A02E4BC201CD3207E0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C72970BC.C323%keir.fraser@xxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD3A074E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091124194401.GA29566@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD3A08EB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091125134144.GA2586@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acpt1R6JpsDVbMDiToWJDEkeQf0uHgADE/AA
Thread-topic: [Xen-devel] Re: APIC rework
Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2009 at 10:43:47AM +0800, Zhang, Xiantao wrote:
>> Konrad Rzeszutek Wilk wrote:
>>>> At least dom0 parses this info from DSDT, so we can't have the
>>>> assuption whether it is used or not, I think. And I also agree to
>>>> add a new physdev_op to handle this case, and it should be better
>>>> way to go. Based on this idea, I worked out the patch, attached! 
>>>> In this patch, we introduced a new physdev_op PHYSDEVOP_setup_gsi
>>>> for each GSI setup, and each domain can require to map each GSI in
>>>> this case. In addition, I believe it is very safe to port the
>>>> hypervisor patch to xen-3.4-x tree and keeps pv_ops dom0 running
>>>> on it, since no logic is changed.  BTW, I also tested apic and
>>>> non-apic cases, they works fine after applying the patches.
>>> But I don't think you tested PCI front and PCI back.
>>> Mainly these lines worry me (can you inline the patch next time
>>> too, please): 
>>> +               map_irq.domid = DOMID_SELF;
>>> +               map_irq.type = MAP_PIRQ_TYPE_GSI;
>>> +               map_irq.index = gsi;
>>> +               map_irq.pirq = irq;
>>> +               rc = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq,
>>> &map_irq); 
>>> For PCI passthrough to work, the domid needs to be for the guest
>>> domain, while in this case it is set to Dom0.
>>> There is already a method of extracting the domain id for PCI
>>> devices passed to the guest. Look in the 'xen_create_msi_irq'
>>> function. 
>> Could you detail the concern ?  This hypercall is only related to
>> GSI, not MSI, why it has side-effect about pci passthrough ? 
> This is for PV guests _without_ using QEMU. They are using the PCI
> backend to "enable" a device (drivers/xen/pciback and
> drivers/pci/xen-pcifront.c). 
> The front and back-end communicate the IRQ number (GSI) to the guest
> when enabling a INTx PCI device (not MSI ones).
> Then the PV guest can bind the IRQ (GSI) number to its own event
> channel and 
> have fully working PCI device.
> With your change, the privileged domain pins the device to itself,
> not to 
> other domains.

But I think dom0 should own the device first during boot, and then assign it to 
PV guest when this device is required by pcifront?  Basically, we don't know 
which devices should be reserved for non-previleged domains, right ? So I think 
the GSI should be initialized and bind to dom0 when dom0 boots?  Once the 
devices is assigned to PV guests, it maybe need to do the unmapping operation 
about the GSI from dom0 and do mapping for the domU. 

BTW, I just met a strange issue with the  function xen_create_msi_irq you 
mentioned, and it blocks initialization of SR-IOV devices' VFs , and I think it 
should be a bug.
In the function xen_create_msi_irq, there is one line as following to get the 
domid of the specified device, but a strange domid(0xfff0) is returned by this 
call, could you help to check whether this strange domid is from?   
domid = rc = xenbus_walk( "/local/domain/0", get_domid_for_dev, dev);

Xen-devel mailing list

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