Jesse Barnes wrote: >> "Dexuan Cui" wrote: >> Hi Matthew, >> Currently pci_reset_function() is mainly used by >> kvm_vm_ioctl_assign_device() and kvm_free_assigned_device(). In the >> case of KVM VT-d, in host the driver of the device assigned to HVM >> guest is not the "genuine" one -- it should always be the dummy >> driver "pci-stub" or NULL, because the "genuine" driver in HVM guest >> would control the device and in host we should not load an actual >> driver for the device. >> >> So adding a 'reset' field into struct pci_driver doesn't sound like a >> good idea to me. And the existing pci_dev_reset() has been there for >> quite a while, so I think adding pci_dev_specific_reset() into >> pci_dev_reset() should be good. > > Moving things to a ->reset member function seems like a good cleanup. > Drivers that need specific reset funcs could override it and call the > default one as necessary from their private functions. Hi Jesse and Matthew, As I mentioned before, the "Drivers that need the reset funcs" can only be pciback and pci-stub, and even the device we try to reset and assign to guest doesn't have a driver bound. I think the "reset" function is something PCI-generic and is not "driver-specific", so I guess we should not put it into the struct pci_driver. > Can you take a look at that and see if it would be much harder than > the scheme you proposed? I think it would end up a bit cleaner, and > shouldn't be much more code... In drivers/pci/pci.c, looks replacing pci_dev_reset() with dev->reset() can't make the code much cleaner. I guess I don't catch on here. Could you please check in the patches first and then do any cleanup you want? :-) Thanks, -- Dexuan-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
