From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrPnq-0002LX-83 for qemu-devel@nongnu.org; Mon, 02 Jun 2014 06:49:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WrPnk-0001wy-Pb for qemu-devel@nongnu.org; Mon, 02 Jun 2014 06:49:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrPnk-0001wP-Gx for qemu-devel@nongnu.org; Mon, 02 Jun 2014 06:49:12 -0400 Date: Mon, 2 Jun 2014 13:49:35 +0300 From: "Michael S. Tsirkin" Message-ID: <20140602104935.GA26816@redhat.com> References: <1401452542-11080-1-git-send-email-arei.gonglei@huawei.com> <1401452542-11080-7-git-send-email-arei.gonglei@huawei.com> <1401695898.22391.22.camel@nilsson.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401695898.22391.22.camel@nilsson.home.kraxel.org> Subject: Re: [Qemu-devel] [PATCH 6/6] usb: tag usb host controller as hotpluggable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: weidong.huang@huawei.com, arei.gonglei@huawei.com, luonengjun@huawei.com, qemu-devel@nongnu.org, peter.huangpeng@huawei.com On Mon, Jun 02, 2014 at 09:58:18AM +0200, Gerd Hoffmann wrote: > On Fr, 2014-05-30 at 20:22 +0800, arei.gonglei@huawei.com wrote: > > From: Gonglei > > > > usb host controller should be able to support hotplug/unplug, > > as the same as the other pci devices, which not enable > > multifunction capability. > > > > BTW, the qemu have not the capability to support > > hotplug mulitfuncition pci devices at present. > > I'd like to keep hotplug disabled for the multifunction configurations. > Which means we have to switch that per device instance, not per device > class. Not sure what the best way to do that is. mst, suggestions? > > cheers, > Gerd Override the "hotpluggable" property in some way, and teach qdev to check it? Alternatively, teach hotplug that it can fail? Again it's a question of teaching device_set_realized and qdev_unplug that these can fail. -- MST