qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qdev-monitor: Avoid exiting when hot-plugging t


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] qdev-monitor: Avoid exiting when hot-plugging two devices with the same bootindex value
Date: Mon, 16 Sep 2013 17:34:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

Il 16/09/2013 17:14, Michael S. Tsirkin ha scritto:
> On Mon, Sep 16, 2013 at 12:11:35PM +0200, Paolo Bonzini wrote:
>> Il 16/09/2013 11:54, Marcel Apfelbaum ha scritto:
>>> On Thu, 2013-09-12 at 13:04 +0200, Markus Armbruster wrote:
>>>> Marcel Apfelbaum <address@hidden> writes:
>>>>
>>>>> On Thu, 2013-09-12 at 11:43 +0200, Markus Armbruster wrote:
>>>>>> Paolo Bonzini <address@hidden> writes:
>>>>>>
>>>>>>> Il 11/09/2013 20:26, Marcel Apfelbaum ha scritto:
>>>>>>>> Qemu is expected to quit if the same boot index value is used by
>>>>>>>> two devices.
>>>>>>>> However, hot-plugging a device with a bootindex value already used 
>>>>>>>> should
>>>>>>>> fail with a friendly message rather than quitting a running VM.
>>>>>>>
>>>>>>> I think the problem is right where QEMU exits, i.e. in
>>>>>>> add_boot_device_path.  This function should return an error instead, via
>>>>>>> an Error ** argument.
>>>>>>
>>>>>> Agree.
>>>
>>> I understood that the boot order is passed in fw cfg and updated only once 
>>> at
>>> "machine done". There is no update of this list after this point.
>>> Modifying the boot order from monitor does not work at all.
>>>
>>> So in order to solve this issue we can:
>>> 1. Don't allow use of bootindex at hot-plug
>>> 2. Change the architecture so boot order changing during hot-plug will be 
>>> possible.
>>
>> This is done relatively easily in add_boot_device_path (check the
>> qdev_hotplug variable and return an error if it is 1).
> 
> This refers to 1) here? That's nice but it's not really all that helpful.

True, but the error propagation changes are the base for both cases, and
(1) is just 4 lines of code.  So this seems like a plan to me: do the
error propagation changes and (1), then we can revert those four lines
when (2) is ready.

Paolo




reply via email to

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