[Xen-devel] RE: [PATCH][RFC] fix some spinlock issues in vmsi

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

I was confused by this also when I try to working on the pci_dev lock.

Current implementation did't assume the device is not owned by guest, that 
means the IOMMU/MSI are both maybe enabled for a guest when dom0 try to invoke 
the PHYSDEVOP_manage_pci_remove hypercall. This cause a lot of race condition 
issue and makes the pci pass-through very complex.

Maybe we can simplify through two step:

a) Instead of let Xen HV to handle the situation that the device is still owned 
by other guest, we can have pciback to do that before this hypercall is 
invoked. For PV driver domain it will be simple since dom0's kernel should 
invoke PCIback's remove() function. For HVM domain, I think it should be ok for 
stubdomain environment. This will make HV simpler and robust and didn't make 
thing worse.

b) Find some mechanism so that dom0 can cause virtual hotplug to guest, then 
hotplug in host side will not cause trouble to guest. There are virtual hotplug 
for PV guest but it  is async method, not sure if that can be integrated with 
dom0's hotplug event handling. 

Not sure if this is feasible.

CC Esp and Winston also.

Thanks
Yunhong Jiang


xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <> wrote:
> On 06/03/2009 17:43, "Qing He" <qing.he@xxxxxxxxx> wrote:
> 
>>> Do you mean deinitialised and unloaded the device driver?
>> 
>> Yes, the racey condition we just talked happens here. Consider
>> the following case, when remove_pci_device is called, the device
>> data structure is removed by the hypervisor. But there is no
>> guarauntee in the hypervisor that guest already has knowledge,
>> for example the guest may continue to access the device resources.
>> It's in this case msixtbl_{read,write} has a little racey condition.
>> 
>> I don't think this scenario is desirable, but does it happen in the
>> current logic?
> 
> Uh, well since dom0 is in fact mostly in charge of PCI access,
> there's not
> much we can do in Xen to enforce this. At that level we kind of have to
> assume that dom0 has sequenced hotplug/hotunplug sensibly.
> 
> -- Keir
> 
> 
> 
> _______________________________________________
> 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