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);
^^^^^^^
Xiantao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home