Daniel P. Berrange wrote: > On Wed, Dec 09, 2009 at 08:44:06PM +0100, Alexander Graf wrote: > >> Daniel P. Berrange wrote: >> >>> On Wed, Dec 09, 2009 at 08:18:21PM +0100, Alexander Graf wrote: >>> >>> >>>> Daniel P. Berrange wrote: >>>> >>>> >>>>> Unconditionally telling people to run rmmod is a pretty dangerous thing >>>>> todo. If they typod and gave the PCI addr of their disk controller instead >>>>> of the NIC, they'll be less than happy at the results of our recommended >>>>> command to "fix" the error. Likewise if they have multiple devices using >>>>> the same driver & just want to assign one of them. I think it is safer to >>>>> just have the first bit of your proposed error message >>>>> >>>>> "The device 04:00.0 is in use by the kernel driver 'igb'." >>>>> >>>>> >>>>> NB 'rmmod' is not the ideal approach for PCI assignment. It is better >>>>> to explicitly re-bind the device to 'pcistub' because that ensures that >>>>> no other driver will ever be able to reclaim the device. >>>>> >>>>> >>>>> >>>> Oh - mind to get into detail there? It'd be great if we could tell users >>>> an even better way to unbind their device from the driver than rmmod :) >>>> >>>> >>> The direct low level sysfs way involves the following steps >>> >>> // Tell pci-stub to accept a particular vendor+product ID binding >>> # echo "8086 27cb" > /sys/bus/pci/drivers/pci-stub/new_id >>> >>> // Remove device from existing PCI driver >>> # echo "00:1d.3" > /sys/bus/pci/drivers/e1000/unbind >>> >>> // Add device to pci-stub PCI driver >>> # echo "00:1d.3" > /sys/bus/pci/drivers/pci-stub/bind >>> >>> // Tell pci-stub to stop accepting a vendor+product ID binding >>> # echo "8086 27cb" > /sys/bus/pci/drivers/pci-stub/remove_id >>> >>> The reason for that last step is that if you have multiple devices of >>> the same vendor+product, you don't want a later hotplug event to bind >>> the new device to pci-stub too ! >>> >>> >> So what would you think if we'd just print out those 4 commands to the >> user, so people who don't use libvirt still get guidance when using >> -pcidevice :). They should be fairly easy to construct from the >> information we have. >> > > I think it is better to put that information in the QEMU docs for the > -pcidevice argument where it can be properly explained in detail, > outlining the potential consequences of the actions. The error message > could direct people to the docs. > I personally like programs that guide me, so I guess it should be in both. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
