Re: [Qemu-devel] [PATCH] qdev-monitor: Avoid exiting when hot-plugging two devices with the same bootindex value

[Michael S. Tsirkin]

On Mon, Sep 16, 2013 at 05:34:04PM +0200, Paolo Bonzini wrote:
> 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

I'm fine with applying error propagation, but maybe not (1).

Basically if you accept incorrect code the result often
is that controbutor disappears and it's never completed,
others are discouraged from addressing the problem because
incorrect code created maintainance issues, and
a half-solved problem is a less interesting target
than an unsolved one.

So if a contributor basically says he does not want
to address the complete problem, we should weight
carefully whether we want to be stuck with
half a solution for a long time.

In this case, I don't think it's justified.

-- 
MST