From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56511 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OE4dJ-0005tJ-9l for qemu-devel@nongnu.org; Mon, 17 May 2010 14:01:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OE4dF-00048S-Vy for qemu-devel@nongnu.org; Mon, 17 May 2010 14:01:41 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:46135) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OE4dF-00048F-RT for qemu-devel@nongnu.org; Mon, 17 May 2010 14:01:37 -0400 Received: by vws1 with SMTP id 1so1058446vws.4 for ; Mon, 17 May 2010 11:01:36 -0700 (PDT) Message-ID: <4BF1847D.9090603@codemonkey.ws> Date: Mon, 17 May 2010 13:01:33 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc References: <1273086712-29163-1-git-send-email-lcapitulino@redhat.com> <1273086712-29163-2-git-send-email-lcapitulino@redhat.com> <4BEC031D.6020506@redhat.com> <4BED6F85.50309@redhat.com> <4BED83BD.8000604@redhat.com> <4BF107E1.2020600@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: bazulay@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , juzhang@redhat.com, Avi Kivity , Gerd Hoffmann On 05/17/2010 06:19 AM, Markus Armbruster wrote: > Avi Kivity writes: > > >> On 05/17/2010 11:27 AM, Markus Armbruster wrote: >> >>> >>> >>>>>> A slot is the hotpluggable entity. Open your computer and you can >>>>>> actually see them. >>>>>> >>>>>> >>>>>> >>>>> QEMU doesn't really know that. >>>>> >>>>> >>>>> >>>> How can that be? Do we signal hotplug notifications to a function or >>>> to a slot? >>>> >>>> Can we hotplug a single function in an already occupied slot? >>>> >>>> >>> What I meant to say: we have no concept of "slot" in the higher level >>> interfaces, we have only bus and device. >>> >>> If a PCI device has multiple functions, we have a separate qdev device >>> for each function. You can't unplug a "slot" (concept doesn't exist in >>> qdev), only a qdev device. Naturally, when you unplug a qdev device, >>> all functions in the same PCI slot need to go. This happens deep down >>> in the bowels of ACPI, in piix4_device_hotplug(). qdev is not aware of >>> this magic relation between the qdev devices for functions in the same >>> slot. >>> >>> >> IMO, that's a serious bug. A slot is a user visible entity, both in >> that devices can only be hotplugged only as slots, not functions, and >> to determine the maximum number of devices you can add. If the user >> knows about it, qemu should too. >> >> We can easily represent a slot/device as a qbus with each of the >> functions as devices attached to it. >> > Dunno. Gerd, what do you think? > Personally, I would think slots should be a property of the PCI bus (ala qdev). It's something that you probably want to be configurable since it's not very common to see machines with 32 slots. That said, since it affects the ACPI tables, it may be difficult to do in practice. Regards, Anthony Liguori