[Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property

Janne Huttunen posted 6 patches 7 years ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/cover.1489494746.git.janne.huttunen@nokia.com
Test checkpatch passed
Test docker passed
bootdevice.c             | 112 ++++++++++++++++++++++++++++++++++++-----------
hw/net/virtio-net.c      |   3 ++
hw/nvram/fw_cfg.c        |   2 +
hw/ppc/spapr.c           |   2 +
hw/s390x/ipl.c           |   2 +
hw/scsi/scsi-bus.c       |   3 ++
hw/virtio/virtio-pci.c   |   2 +
include/hw/block/block.h |   1 +
include/net/net.h        |   1 +
include/sysemu/sysemu.h  |   4 ++
10 files changed, 106 insertions(+), 26 deletions(-)
[Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Janne Huttunen 7 years ago
This series implements a "bootonceindex" property for setting the boot
source priorities for the next boot only. In principle it is supposed
to do the same thing as the '-boot once=' argument but in a compatible
way with the 'bootindex' mechanism.

The basic idea is to have a second list that is sorted by the values
of the "bootonceindex" properties. When the boot order is requested,
the new list is returned if it is not empty and the list is cleared.
The normal bootindex list is only used when there are no devices on
the "once" list.

So far I have only added the support for a couple of devices and
lightly tested it on x86_64 system emulation.

Some questions:

  - Is there already some (reasonable) way to accomplish the same
    effect in QEMU?

  - Does this approach make sense? Any better ideas?

  - Any suggestions for better function / property names?

  - Should the series be split or squashed differently? I tried to
    make it easy to review, but...

  - Are the object life times (no dangling pointers left behind)
    and (lack of) locking correct? As far as I can see, they should
    be, but someone with more experience with this codebase may see
    something I don't...

  - If this approach is going to be merged, any volunteers for
    converting the rest of the devices? Or can the conversion be
    left to be done one by one at some later date? I can try to
    convert more of them, but testing them all is likely not going
    to be possible.

  - Any other suggestions/ideas/comments?


Janne Huttunen (6):
  Re-factor bootdevice list handling, pt1.
  Re-factor bootdevice list handling, pt2.
  Add support for "bootonceindex" property.
  Clear the boot once list after it has been used.
  Support "bootonceindex" property for virtio-net interfaces.
  Support "bootonceindex" property for SCSI disks.

 bootdevice.c             | 112 ++++++++++++++++++++++++++++++++++++-----------
 hw/net/virtio-net.c      |   3 ++
 hw/nvram/fw_cfg.c        |   2 +
 hw/ppc/spapr.c           |   2 +
 hw/s390x/ipl.c           |   2 +
 hw/scsi/scsi-bus.c       |   3 ++
 hw/virtio/virtio-pci.c   |   2 +
 include/hw/block/block.h |   1 +
 include/net/net.h        |   1 +
 include/sysemu/sysemu.h  |   4 ++
 10 files changed, 106 insertions(+), 26 deletions(-)

-- 
2.7.4


Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Gerd Hoffmann 7 years ago
  Hi,

>   - Does this approach make sense? Any better ideas?

What is the use case?

Sometimes I'm wondering why we actually need the "once" thing.  Looks
like people use it for installs, but I fail to see why.  I usually
configure my guests with hard disk as bootindex=1 and install media
(cdrom or net) as bootindex=2.  In case the hard disk is blank it
automatically falls back to the second and boots the installer, and when
the installer is finished the hard disk isn't blank any more and the
just installed system gets booted ...

cheers,
  Gerd


Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Janne Huttunen 7 years ago
> >   - Does this approach make sense? Any better ideas?
>  
> What is the use case?

The short answer: emulating real hardware.

Since real HW has this capability, there exist certain
auxiliary systems that are built on it. Having similar
semantics available in QEMU allows me to build a virtual
machine that works with these systems without modifying
them in any way.

Also, the support I'm after already almost was in QEMU
('-boot once='). It just didn't quite provide the
functionality I wanted i.e. the 'bootindex' like operation.
This patch series tries to bridge that gap. But hey, I
wasn't sure if this was useful for other people too, and
that's why the RFC.

In principle I agree with you that in some specific cases
QEMU has other means of doing things that necessarily don't
exist in real HW. Obviously systems that are built for real
HW don't use any such QEMU specific methods. Again, in some
specific cases it might be possible to get close enough
semantics without real "boot once" support and in others it
probably won't be. Note that part of the semantics I'm after
is that the "boot once" order can be set while the system is
up and running. It may or may not be strictly necessary
depending on the specific use case, but that's the way the
real HW works.



Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Gerd Hoffmann 7 years ago
   Hi,

> The short answer: emulating real hardware.
> 
> Since real HW has this capability, there exist certain
> auxiliary systems that are built on it. Having similar
> semantics available in QEMU allows me to build a virtual
> machine that works with these systems without modifying
> them in any way.

Ok, that is reason enough.

Adding bootonceindex everywhere doesn't look like the best plan to me
though.  Possibly we can pimp up bootindex in a backward-compatible way?
Something like bootindex=<normal>[.<once>] ?

cheers,
  Gerd


Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Janne Huttunen 7 years ago
On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote:
> >
> > The short answer: emulating real hardware.
> 
> Ok, that is reason enough.
> 
> Adding bootonceindex everywhere doesn't look like the best plan to me
> though.  Possibly we can pimp up bootindex in a backward-compatible
> way?
> Something like bootindex=<normal>[.<once>] ?

That would (likely) avoid modifying all devices, but wouldn't
that make the 'bootindex' property a string (now: 'int32')
and thus change the QOM API?

I did consider making device_add_bootindex_property() to
automatically add the new property too, but since that API
is currently such that the _caller_ provides the name of the
added property, it would mean that the function would need
to generate the second name using some magic mangling rule
and that didn't seem very nice to me. Of course the API could
be modified so that the caller provides two names, but then
we are already back to modifying all relevant devices.



Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Gerd Hoffmann 7 years ago
On Do, 2017-03-16 at 11:46 +0200, Janne Huttunen wrote:
> On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote:
> > >
> > > The short answer: emulating real hardware.
> > 
> > Ok, that is reason enough.
> > 
> > Adding bootonceindex everywhere doesn't look like the best plan to me
> > though.  Possibly we can pimp up bootindex in a backward-compatible
> > way?
> > Something like bootindex=<normal>[.<once>] ?
> 
> That would (likely) avoid modifying all devices, but wouldn't
> that make the 'bootindex' property a string (now: 'int32')
> and thus change the QOM API?

Good point.  I was thinking about the cmd line only where it is a string
anyway.

> I did consider making device_add_bootindex_property() to
> automatically add the new property too, but since that API
> is currently such that the _caller_ provides the name of the
> added property, it would mean that the function would need
> to generate the second name using some magic mangling rule
> and that didn't seem very nice to me.

I think the only case where this is something != "bootindex" is the
floppy controller, which has bootindexA and bootindexB for the two
drives.  So name mangling doesn't look too bad to me.  Maybe we could
just add a "first-" or "once-" prefix.  But the second bootindex still
needs to be stored somewhere in the device state struct ...

> Of course the API could
> be modified so that the caller provides two names, but then
> we are already back to modifying all relevant devices.

... so I guess there isn't really some way around that.

cheers,
  Gerd


Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Eric Blake 7 years ago
On 03/16/2017 04:46 AM, Janne Huttunen wrote:
> On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote:
>>>
>>> The short answer: emulating real hardware.
>>
>> Ok, that is reason enough.
>>
>> Adding bootonceindex everywhere doesn't look like the best plan to me
>> though.  Possibly we can pimp up bootindex in a backward-compatible
>> way?
>> Something like bootindex=<normal>[.<once>] ?
> 
> That would (likely) avoid modifying all devices, but wouldn't
> that make the 'bootindex' property a string (now: 'int32')
> and thus change the QOM API?

Is there any way to make use of an alternate that supports both int and
string simultaneously?  But see also Markus' recent addendum on the
difficulties of supporting multiple types on command-line vs. through QMP:

https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg04125.html

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Paolo Bonzini 7 years ago

On 15/03/2017 07:58, Janne Huttunen wrote:
> 
> Since real HW has this capability, there exist certain
> auxiliary systems that are built on it. Having similar
> semantics available in QEMU allows me to build a virtual
> machine that works with these systems without modifying
> them in any way.

How does real hardware do it?  I suppose you'd do it with a firmware
setup menu or something like that; would it be enough to add a way to
modify bootindex during runtime?

Paolo

Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Janne Huttunen 7 years ago
On Tue, 2017-03-21 at 18:55 +0100, Paolo Bonzini wrote:
> 
> > Since real HW has this capability, there exist certain
> > auxiliary systems that are built on it. Having similar
> > semantics available in QEMU allows me to build a virtual
> > machine that works with these systems without modifying
> > them in any way.
>
> How does real hardware do it?  I suppose you'd do it with a firmware
> setup menu or something like that; would it be enough to add a way to
> modify bootindex during runtime?

On the real hardware the "boot once" really means *once*
i.e. it only affects the next reboot regardless of how
the next boot is triggered (reset button, power button,
software, etc.). After the next boot the normal boot
order is automatically restored.

Theoretically it should be possible to get a close
approximation of this by changing the main boot order,
waiting for the boot to happen and then restoring the
original order back. This would require having some
process that constantly monitors what QEMU is doing so
that it can notice when the boot happens and then
restore the order. I'm trying to avoid having such
a process if possible, which in this case means that
QEMU would need to restore the order by itself.



Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Paolo Bonzini 7 years ago

----- Original Message -----
> From: "Janne Huttunen" <janne.huttunen@nokia.com>
> To: "Paolo Bonzini" <pbonzini@redhat.com>, "Gerd Hoffmann" <kraxel@redhat.com>
> Cc: qemu-devel@nongnu.org
> Sent: Wednesday, March 22, 2017 7:36:54 AM
> Subject: Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
> 
> On Tue, 2017-03-21 at 18:55 +0100, Paolo Bonzini wrote:
> > 
> > > Since real HW has this capability, there exist certain
> > > auxiliary systems that are built on it. Having similar
> > > semantics available in QEMU allows me to build a virtual
> > > machine that works with these systems without modifying
> > > them in any way.
> >
> > How does real hardware do it?  I suppose you'd do it with a firmware
> > setup menu or something like that; would it be enough to add a way to
> > modify bootindex during runtime?
> 
> On the real hardware the "boot once" really means *once*
> i.e. it only affects the next reboot regardless of how
> the next boot is triggered (reset button, power button,
> software, etc.). After the next boot the normal boot
> order is automatically restored.

Understood---my question is how you would set up the alternate
boot order: is it something like "keep a button pressed while
turning on", or something written in NVRAM, or something else
that is completely different?

Paolo

> Theoretically it should be possible to get a close
> approximation of this by changing the main boot order,
> waiting for the boot to happen and then restoring the
> original order back. This would require having some
> process that constantly monitors what QEMU is doing so
> that it can notice when the boot happens and then
> restore the order. I'm trying to avoid having such
> a process if possible, which in this case means that
> QEMU would need to restore the order by itself.
> 
> 
> 

Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Huttunen, Janne (Nokia - FI/Espoo) 7 years ago
On Wed, 2017-03-22 at 04:43 -0400, Paolo Bonzini wrote:
> 
> Understood---my question is how you would set up the alternate
> boot order: is it something like "keep a button pressed while
> turning on", or something written in NVRAM, or something else
> that is completely different?

In my case the real hardware has a management processor
on the board and the temporary boot source (and also the
permanent one for that matter) for the main processor can
be set from there. Since neither the BIOS nor the management
firmware are open source, I don't know how it technically
works, but I assume there either is some shared memory
between the main BIOS and the management processor or
alternatively the BIOS talks with the management processor
with some protocol during boot to get the order.

Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Laszlo Ersek 7 years ago
On 03/22/17 10:00, Huttunen, Janne (Nokia - FI/Espoo) wrote:
> On Wed, 2017-03-22 at 04:43 -0400, Paolo Bonzini wrote:
>>
>> Understood---my question is how you would set up the alternate
>> boot order: is it something like "keep a button pressed while
>> turning on", or something written in NVRAM, or something else
>> that is completely different?
> 
> In my case the real hardware has a management processor
> on the board and the temporary boot source (and also the
> permanent one for that matter) for the main processor can
> be set from there. Since neither the BIOS nor the management
> firmware are open source, I don't know how it technically
> works, but I assume there either is some shared memory
> between the main BIOS and the management processor or
> alternatively the BIOS talks with the management processor
> with some protocol during boot to get the order.
> 

I'm generally opposed to the proposed implementation for this feature /
use case; that is, the new "bootonceindex" device property.

(1) My somewhat hand-waving counter-argument is simply the complexity /
confusion that it introduces. See for example recent QEMU commit
c0d9f7d0bced ("docs: Add a note about mixing bootindex with "-boot
order"", 2017-02-28).

Even if the proposed solution keeps the "bootorder" fw_cfg file intact,
and firmware wouldn't have to look at other fw_cfg files -- I can
already guarantee that OVMF will not look at other fw_cfg files --, the
command line changes look undesirable to me.

(2) My more technical counter-arguments are:

(2a) Exposing this in the libvirt domain XML would be a huge pain.
AFAICS, libvirt already doesn't expose "-boot once" in the domain XML,
which is a *good* thing.

(2b) With the proposed change, "having rebooted once" becomes explicit
runtime state that is guest-controlled. As such, it would have to be
migrated. Assume that you start the guest on the source host, using both
bootindex and bootonceindex properties. Then, for migration, libvirt (or
the user, manually) starts QEMU on the target host using the same
command line. After migration, if the guest reboots on the target host,
its behavior should depend on whether said reboot is its first reboot
since launching the domain, so the fact whether it rebooted on the
source host should reach the target host.


I think you must already have a means to massage the management
processor to change the boot order, for the next boot. Are you doing
that massaging in code that runs on the main processor? If so, that
means the "guest code" is highly privileged, as it can control outside
components in order to influence the boot order.

For that, I can offer the following analogy:

- use a guest with libvirt

- whenever you want to modify the boot order from within the guest,
  ssh back out to the host, and use virsh-dumpxml (--inactive),
  the xmlstarlet utility, and virsh-define, to dump, edit, and save the
  domain XML non-interactively. Xmlstarlet is extremely versatile for
  modifying domain XMLs (or any other kinds of XMLs), and virsh-define
  explicitly supports the case when the domain is already running.

  In a normal virtualization environment, this would be a huge security
  hole, of course, but you are already manipulating the management
  processor from code that runs on the main processor. Exact same
  privilege escalation.

- whenever you want to relaunch the domain fully (i.e., restart QEMU
  with a new command line), again ssh out to the host, and start a
  process (a shell script) in the background. The script should first
  initiate a domain shutdown (virsh-shutdown), then wait for domain
  termination (virsh-qemu-monitor-event, and see the SHUTDOWN event in
  "qapi/event.json"), then start the domain (virsh start). Which is
  when the modified boot order will take effect.


Alternatively, if you are fine using OVMF (as UEFI firmware) within the
guest, to run your payload, you can try the following commands, to set
the BootNext UEFI variable & to reboot:

  efibootmgr --bootnext XXXX
  reboot

While OVMF heavily massages the UEFI boot order (based on the
"bootorder" fw_cfg file), *if* you stick with a constant set of
bootindex properties (== constant boot order setting in the libvirt
domain XML), then most of the UEFI BootXXXX variables that you get to
see in the guest *should* be stable, and the above commands should
hopefully work (no guarantees though).

Thanks
Laszlo

Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Janne Huttunen 7 years ago
On Wed, 2017-03-22 at 11:51 +0100, Laszlo Ersek wrote:
> 
> I'm generally opposed to the proposed implementation for this feature
> /
> use case; that is, the new "bootonceindex" device property.
> 
> (1) My somewhat hand-waving counter-argument is simply the complexity
> /
> confusion that it introduces. See for example recent QEMU commit
> c0d9f7d0bced ("docs: Add a note about mixing bootindex with "-boot
> order"", 2017-02-28).

I agree that it may be confusing, but I was under the
(possibly false?) impression that the "-boot order" was on
its way to being deprecated. I thought supporting the same
functionality on "bootindex" -based configuration would
actually _help_ eventually getting rid of "-boot order".

Of course it can be argued that the "-boot once" was
always a misfeature and should be removed at the same time,
but as it stands I find it even more confusing that there
exists this "bootindex" mechanism but "-boot once" isn't
compatible with it and no compatible alternative seems to
exist at all.

> Even if the proposed solution keeps the "bootorder" fw_cfg file
> intact,
> and firmware wouldn't have to look at other fw_cfg files -- I can
> already guarantee that OVMF will not look at other fw_cfg files --,
> the
> command line changes look undesirable to me.

The current implementation doesn't require any firmware
changes.

> (2) My more technical counter-arguments are:
> 
> (2a) Exposing this in the libvirt domain XML would be a huge pain.
> AFAICS, libvirt already doesn't expose "-boot once" in the domain
> XML,
> which is a *good* thing.

I'm nowhere nearly qualified to comment on that so I'll leave
it to others.

> (2b) With the proposed change, "having rebooted once" becomes
> explicit
> runtime state that is guest-controlled. As such, it would have to be
> migrated. Assume that you start the guest on the source host, using
> both
> bootindex and bootonceindex properties. Then, for migration, libvirt
> (or
> the user, manually) starts QEMU on the target host using the same
> command line. After migration, if the guest reboots on the target
> host,
> its behavior should depend on whether said reboot is its first reboot
> since launching the domain, so the fact whether it rebooted on the
> source host should reach the target host.

Whether the first boot has happened or not is reflected in
the values of the "bootonceindex" properties. The current
implementation resets them back to -1 when the boot happens.
I'm not qualified to say if that is sufficient or not, but
if it isn't don't you already have problems migrating other
things? If e.g. someone sets the "bootindex" property while
the system is running, is that going to get migrated? If it
is, migrating the "bootonceindex" values the same way should
be sufficient, no?

You can probably tell that I'm not very familiar with the
migration and I must admit that I did not think about it
at all when doing the implementation, but things like this
are exactly the reason I wanted to get comments on the idea.

> I think you must already have a means to massage the management
> processor to change the boot order, for the next boot. Are you doing
> that massaging in code that runs on the main processor?

No, the changes are made externally. My setup is such that
first there is a computer that has a main processor with
an attached management processor. Then there is a second
external system that remotely monitors and controls the
first one. Part of what the second system does requires
setting a temporary boot order for the next reboot of the
first system every now and then. Many of the used components
are beyond my control (like e.g. operating systems etc.)
meaning that I either cannot modify them or doing so would
make the whole exercise moot. All this exists in real
hardware, but since there's never enough hardware available
and there are better uses for it, I tried to set up a virtual
machine that could act as a cheap substitute.


Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Laszlo Ersek 7 years ago
On 03/22/17 14:58, Janne Huttunen wrote:
> On Wed, 2017-03-22 at 11:51 +0100, Laszlo Ersek wrote:
>>  
>> I'm generally opposed to the proposed implementation for this feature
>> /
>> use case; that is, the new "bootonceindex" device property.
>>
>> (1) My somewhat hand-waving counter-argument is simply the complexity
>> /
>> confusion that it introduces. See for example recent QEMU commit
>> c0d9f7d0bced ("docs: Add a note about mixing bootindex with "-boot
>> order"", 2017-02-28).
> 
> I agree that it may be confusing, but I was under the
> (possibly false?) impression that the "-boot order" was on
> its way to being deprecated. I thought supporting the same
> functionality on "bootindex" -based configuration would
> actually _help_ eventually getting rid of "-boot order".
> 
> Of course it can be argued that the "-boot once" was
> always a misfeature and should be removed at the same time,

Yes, that's my argument.

> but as it stands I find it even more confusing that there
> exists this "bootindex" mechanism but "-boot once" isn't
> compatible with it and no compatible alternative seems to
> exist at all.

All of the "-boot" options have guest architecture and firmware-specific
behavior (they are even documented so, in both the libvirt domain XML
docs and the QEMU manual page).

For example, "-boot order" is translated to x86 CMOS settings that are
unusable in any firmware that isn't "legacy x86 BIOS".

> 
>> Even if the proposed solution keeps the "bootorder" fw_cfg file 
>> intact, and firmware wouldn't have to look at other fw_cfg files --
>> I can already guarantee that OVMF will not look at other fw_cfg
>> files --, the command line changes look undesirable to me.
> 
> The current implementation doesn't require any firmware
> changes.
> 
>> (2) My more technical counter-arguments are:
>>
>> (2a) Exposing this in the libvirt domain XML would be a huge pain. 
>> AFAICS, libvirt already doesn't expose "-boot once" in the domain 
>> XML, which is a *good* thing.
> 
> I'm nowhere nearly qualified to comment on that so I'll leave
> it to others.
> 
>> (2b) With the proposed change, "having rebooted once" becomes 
>> explicit runtime state that is guest-controlled. As such, it would
>> have to be migrated. Assume that you start the guest on the source
>> host, using both bootindex and bootonceindex properties. Then, for
>> migration, libvirt (or the user, manually) starts QEMU on the
>> target host using the same command line. After migration, if the
>> guest reboots on the target host, its behavior should depend on
>> whether said reboot is its first reboot since launching the domain,
>> so the fact whether it rebooted on the source host should reach the
>> target host.
> 
> Whether the first boot has happened or not is reflected in
> the values of the "bootonceindex" properties. The current
> implementation resets them back to -1 when the boot happens.
> I'm not qualified to say if that is sufficient or not, but
> if it isn't don't you already have problems migrating other
> things? If e.g. someone sets the "bootindex" property while
> the system is running, is that going to get migrated?

To my knowledge, currently the bootindex properties cannot be changed
dynamically (for example with monitor commands) after they have been
specified on the QEMU command line.

And, even if some settings can be changed, the question is what agent
changes them. If the management layer (libvirt etc) changes them using
monitor commands, then libvirt itself can keep track of that state, and
then start the QEMU process on the destination  host with a suitably
modified command line.

Whereas, if it is the guest that changes device state, memory state etc,
then those things have to be part of the migration stream.

> If it
> is, migrating the "bootonceindex" values the same way should
> be sufficient, no?

To my knowledge, "bootindex" properties are not migrated now, and they
also need not to, because they never change at runtime.

> You can probably tell that I'm not very familiar with the
> migration and I must admit that I did not think about it
> at all when doing the implementation, but things like this
> are exactly the reason I wanted to get comments on the idea.
> 
>> I think you must already have a means to massage the management
>> processor to change the boot order, for the next boot. Are you doing
>> that massaging in code that runs on the main processor?
> 
> No, the changes are made externally. My setup is such that
> first there is a computer that has a main processor with
> an attached management processor. Then there is a second
> external system that remotely monitors and controls the
> first one. Part of what the second system does requires
> setting a temporary boot order for the next reboot of the
> first system every now and then.

How does this work in more detail?

If the second system sets a temporary boot order for the first system
"every now and then", which I guess entails on-demand talking to the
first system's management processor, then how can you replace that with
a static QEMU command line (with the proposed bootonceindex property)?

It suggests that you are able to start QEMU processes on demand, if for
nothing else then to set the bootonceindex properties.

> Many of the used components
> are beyond my control (like e.g. operating systems etc.)
> meaning that I either cannot modify them or doing so would
> make the whole exercise moot. All this exists in real
> hardware, but since there's never enough hardware available
> and there are better uses for it, I tried to set up a virtual
> machine that could act as a cheap substitute.

I'm not saying that the use case is without merit. My point is that this
new property would introduce obscure interactions with other components
in the virt stack around QEMU, and it could have a significant
maintenance footprint, while the feature does look niche (to me anyway).
If there is another way to achieve what you need, possibly using other
tools as well, I suggest that we research that more (which is why we
keep inquiring about your setup I guess).

Thanks
Laszlo

Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Janne Huttunen 7 years ago
On Wed, 2017-03-22 at 15:36 +0100, Laszlo Ersek wrote:
> 
> To my knowledge, currently the bootindex properties cannot be changed
> dynamically (for example with monitor commands) after they have been
> specified on the QEMU command line.

Yes they can, via QMP:

{'execute': 'qom-get', 'arguments': { 'path': 'scsi0.0/child[0]',
'property': 'bootindex' }}
{"return": 10}

{'execute': 'qom-set', 'arguments': { 'path': 'scsi0.0/child[0]',
'property': 'bootindex', 'value': 11 }}
{"return": {}}

{'execute': 'qom-get', 'arguments': { 'path': 'scsi0.0/child[0]',
'property': 'bootindex' }}
{"return": 11}


I have no idea if doing so breaks something, like e.g.
migration, but it definitely can be done.

> And, even if some settings can be changed, the question is what agent
> changes them. If the management layer (libvirt etc) changes them
> using
> monitor commands, then libvirt itself can keep track of that state,
> and
> then start the QEMU process on the destination  host with a suitably
> modified command line.
> 
> Whereas, if it is the guest that changes device state, memory state
> etc,
> then those things have to be part of the migration stream.

True.

> > If it
> > is, migrating the "bootonceindex" values the same way should
> > be sufficient, no?
> To my knowledge, "bootindex" properties are not migrated now, and
> they
> also need not to, because they never change at runtime.

Like demonstrated above, they can change, but of course
there might be an assumption that they won't change
"unexpectedly".

> If the second system sets a temporary boot order for the first system
> "every now and then", which I guess entails on-demand talking to the
> first system's management processor, then how can you replace that
> with
> a static QEMU command line (with the proposed bootonceindex
> property)?

I'm not. I'm using QMP to change the index dynamically.

> I'm not saying that the use case is without merit. My point is that
> this
> new property would introduce obscure interactions with other
> components
> in the virt stack around QEMU, and it could have a significant
> maintenance footprint, while the feature does look niche (to me
> anyway).

Maybe, and it is definitely good to analyze it. Like I
already admitted, I did not think about migration at all
and there may very well have been other things I have
overlooked too.



Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Laszlo Ersek 7 years ago
On 03/22/17 16:19, Janne Huttunen wrote:
> On Wed, 2017-03-22 at 15:36 +0100, Laszlo Ersek wrote:
>>  
>> To my knowledge, currently the bootindex properties cannot be changed
>> dynamically (for example with monitor commands) after they have been
>> specified on the QEMU command line.
> 
> Yes they can, via QMP:
> 
> {'execute': 'qom-get', 'arguments': { 'path': 'scsi0.0/child[0]',
> 'property': 'bootindex' }}
> {"return": 10}
> 
> {'execute': 'qom-set', 'arguments': { 'path': 'scsi0.0/child[0]',
> 'property': 'bootindex', 'value': 11 }}
> {"return": {}}
> 
> {'execute': 'qom-get', 'arguments': { 'path': 'scsi0.0/child[0]',
> 'property': 'bootindex' }}
> {"return": 11}
> 
> 
> I have no idea if doing so breaks something, like e.g.
> migration, but it definitely can be done.
> 
>> And, even if some settings can be changed, the question is what agent
>> changes them. If the management layer (libvirt etc) changes them
>> using
>> monitor commands, then libvirt itself can keep track of that state,
>> and
>> then start the QEMU process on the destination  host with a suitably
>> modified command line.
>>
>> Whereas, if it is the guest that changes device state, memory state
>> etc,
>> then those things have to be part of the migration stream.
> 
> True.
> 
>>> If it
>>> is, migrating the "bootonceindex" values the same way should
>>> be sufficient, no?
>> To my knowledge, "bootindex" properties are not migrated now, and
>> they
>> also need not to, because they never change at runtime.
> 
> Like demonstrated above, they can change, but of course
> there might be an assumption that they won't change
> "unexpectedly".
> 
>> If the second system sets a temporary boot order for the first system
>> "every now and then", which I guess entails on-demand talking to the
>> first system's management processor, then how can you replace that
>> with
>> a static QEMU command line (with the proposed bootonceindex
>> property)?
> 
> I'm not. I'm using QMP to change the index dynamically.

Wait, if you are already changing the "bootindex" property dynamically
(do I understand that right?), and it even takes effect after guest
reboot, then why is "bootonceindex" necessary at all?

(I apologize, I think I'm confused.)

Thanks
Laszlo

> 
>> I'm not saying that the use case is without merit. My point is that
>> this
>> new property would introduce obscure interactions with other
>> components
>> in the virt stack around QEMU, and it could have a significant
>> maintenance footprint, while the feature does look niche (to me
>> anyway).
> 
> Maybe, and it is definitely good to analyze it. Like I
> already admitted, I did not think about migration at all
> and there may very well have been other things I have
> overlooked too.
> 
> 


Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Janne Huttunen 7 years ago
On Wed, 2017-03-22 at 16:29 +0100, Laszlo Ersek wrote:
> > I'm not. I'm using QMP to change the index dynamically.
> > 
> Wait, if you are already changing the "bootindex" property
> dynamically (do I understand that right?)

No, I'm not changing "bootindex" dynamically. I'm changing
"bootonceindex" dynamically. The point is that whatever
change I'm making is supposed to affect only one boot, the
next one. Since the guest can trigger reboots by itself,
I don't necessarily know when they are going to happen.

Like I said earlier, I can get very close to the semantics
I need if set the "bootindex" and get an event when the
boot happens so that I know when to reset the bootindex
back to the original value. However doing it like that
is (at least in theory) racy if the event isn't synchronous
and it requires some process that actively monitors those
events which I'm trying to avoid.

> ...and it could have a significant maintenance footprint,
> while the feature does look niche (to me anyway).

Whatever I'm currently doing is definitely a niche, but very
similar setting of a one time boot source while the system
is running is e.g. part of the IPMI standard (see "Set
System Boot Options Command" in IPMI Specification), so
the concept itself is not that much of a niche.


Re: [Qemu-devel] [RFC][PATCH 0/6] "bootonceindex" property
Posted by Laszlo Ersek 7 years ago
On 03/23/17 07:53, Janne Huttunen wrote:
> On Wed, 2017-03-22 at 16:29 +0100, Laszlo Ersek wrote:
>>> I'm not. I'm using QMP to change the index dynamically.
>>>  
>> Wait, if you are already changing the "bootindex" property
>> dynamically (do I understand that right?)
> 
> No, I'm not changing "bootindex" dynamically. I'm changing
> "bootonceindex" dynamically. The point is that whatever
> change I'm making is supposed to affect only one boot, the
> next one. Since the guest can trigger reboots by itself,
> I don't necessarily know when they are going to happen.
> 
> Like I said earlier, I can get very close to the semantics
> I need if set the "bootindex" and get an event when the
> boot happens so that I know when to reset the bootindex
> back to the original value. However doing it like that
> is (at least in theory) racy if the event isn't synchronous
> and it requires some process that actively monitors those
> events which I'm trying to avoid.
> 
>> ...and it could have a significant maintenance footprint,
>> while the feature does look niche (to me anyway).
> 
> Whatever I'm currently doing is definitely a niche, but very
> similar setting of a one time boot source while the system
> is running is e.g. part of the IPMI standard (see "Set
> System Boot Options Command" in IPMI Specification), so
> the concept itself is not that much of a niche.
> 

... Okay, I've spoken my mind on this, and have nothing more to add. I'm
still not convinced, but that doesn't mean you can't convince others.
(And you need to convince others more than me, because I'm not a QEMU
maintainer -- I just wanted to voice my opinion, since this was an RFC.)

What really matters to me though is that the "bootorder" fw_cfg file
preserve
- both its current, exclusive role, for communicating the boot order to
the firmware,
- and its syntax & semantics.

Thanks
Laszlo