qemu-devel
[Top][All Lists]
Advanced

[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]