From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [PATCH] Inform users about busy device assignment attempt Date: Wed, 9 Dec 2009 20:14:14 +0000 Message-ID: <20091209201414.GE13487@redhat.com> References: <1260381853-8954-1-git-send-email-agraf@suse.de> <20091209181956.GA13487@redhat.com> <4B1FF7FD.5080407@suse.de> <20091209194030.GD13487@redhat.com> <4B1FFE06.8090909@suse.de> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757638AbZLIUOM (ORCPT ); Wed, 9 Dec 2009 15:14:12 -0500 Content-Disposition: inline In-Reply-To: <4B1FFE06.8090909@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|