于 2011年09月28日 15:39, Wen Congyang 写道:
At 09/28/2011 03:47 PM, Osier Yang Write:This patch is just like commit 2ce90ea296, to init the member of pciDevice before reattachment, otherwise the device won't be unbound from pci_stub, and won't get the original driver (no probing). --- src/qemu/qemu_hostdev.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c index 6f77717..74c817c 100644 --- a/src/qemu/qemu_hostdev.c +++ b/src/qemu/qemu_hostdev.c @@ -292,6 +292,7 @@ void qemuDomainReAttachHostdevDevices(struct qemud_driver *driver, for (i = 0; i< pciDeviceListCount(pcidevs); i++) { pciDevice *dev = pciDeviceListGet(pcidevs, i); + pciDeviceReAttachInit(dev); qemuReattachPciDevice(dev, driver); }The user runs 'virsh attach-device' to pass through host pci device to guest os. We will call the function qemuPrepareHostdevPCIDevices() to bind the pci device to pci-stub, and reset it. If the pci device does not support reset function, we will call pciReAttachDevice() to rollback the things we have done.
True
If the device is alread bound to pci-stub before the user runs 'virsh attach-device', we should do nothing. If the device is not bound to any driver, we should unbound it from pci-stub. If the device is bound to other driver, we should unbound it from pci-stub, and reprobe it.
Ok, I guess you mean this patch breaks following 2 scenarios: 1) the device is bound to pci-stub before attach-device 2) the device is not bound to any driver before attach-device For3), the patch is fine.
With your patch, we can not rollback the things we have done. What problems do you meet?
The problem is if we attach a device bound to other driver with "managed=yes", if it fails on attachment, it will never be reattached to host successfully. As a simple reproduce method, you can try to attach a PCI device after turn off VT-d support. I didn't realize the patch breaks 1) and 2) scenarios. Thanks for pointing it out. Then I guess we lost the original dev->ubind_from_stub/dev->remove_slot/ dev->probe (all of some of them) in manged mode. Need to track more. Osier -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list