Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.

[Markus Armbruster]

Minoru Usui <address@hidden> writes:

> Hi, William, Markus and other people.
>
> On Wed, 23 Feb 2011 10:42:02 +0100
> William Dauchy <address@hidden> wrote:
>
>> Hi Minoru,
>> 
>> On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui <address@hidden> wrote:
>> > I can reproduce, too.
>> > But strangely, it don't occur in case of loading acpiphp driver
>> > to the guest VM on below environment.
>> >
>> >  Host : RHEL6.0
>> >  Guest: RHEL5.5
>> >
>> > Unfortunately, I'm not familiar with qemu-kvm.
>> > I investigated below questions about this problem, but I couldn't resolve 
>> > them.
>> >
>> >  - How to call qdev_free() asynchronously. (How should we fix this problem)
>> >  - Why it don't occur with acpiphp driver
>> >
>> > If anyone knows answer of above questions or its clue, please let me know.
>> 
>> If fact this is not a bug.
>> `qdev_free` is called when the acpi detach succeed in `pciej_write`.
>> The virtual machine has to correctly support acpi signals.
>> Please read the explanation from Markus Armbruster on
>> http://lists.nongnu.org/archive/html/qemu-devel/2011-02/msg02637.html
>
> William, Thank you for your help and telling me about it.
>
> Markus, Thank you for your detailed explanation.
> Basically, I understand behaviour of device_del command.
> The result of pci hotunplug depends on behaviour of guest OS,
> but device_del command doesn't wait hotunplug's result.
>
> May I ask you a question?
> Which device does qemu_device_opts manage?
> just hotplugged to virtual machine? Or hotplugged to guest OS?
>
> By the present implementation, device_add command adds qemu_device_opts 
> immediately, 
> whether guest OS can hotplug the device or not.
> Nevertheless, device_del command waits for the device appropriately 
> until it is hotunplugged by the guest OS.
>
> By Markus's explanation, device_del command can't wait for the device
> which hotunplugged from guest OS.
> So, I feel it's better that qemu_device_opts manages the device
> which hotplugged to guest OS.
>
> If I am wrong, please let me know.

qemu_device_opts holds the currently defined device configurations.  A
device configuration becomes defined the moment its QemuOpts get created
(for -device and device_add: right when the argument gets parsed, which
is *before* the device gets created, let alone plugged).  It ceases to
be defined when device creation fails, or when the device is deleted
after unplug completed.

qemu_device_opts is *not* the set of devices currently plugged in.  That
information is encoded in the device tree.