[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc
Date: Mon, 17 May 2010 13:19:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Avi Kivity <address@hidden> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]