Re: [Qemu-devel] [PATCH v6 05/11] qapi: introduce new cmd option "allowed-in-preconfig"

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Apr 27, 2018 at 05:05:17PM +0200, Igor Mammedov wrote:
> New option will be used to allow commands, which are prepared/need
> to run, during preconfig state. Other commands that should be able
> to run in preconfig state, should be ameded to not expect machine
> in initialized state or deal with it.
> 
> For compatibility reasons, commands that don't use new flag
> 'allowed-in-preconfig' explicitly are not permitted to run in
> preconfig state but allowed in all other states like they used
> to be.
> 
> Within this patch allow following commands in preconfig state:
>    qmp_capabilities
>    query-qmp-schema
>    query-commands
>    query-command-line-options
>    query-status
>    exit-preconfig
> to allow qmp connection, basic introspection and moving to the next
> state.

Looking at what libvirt sends to QEMU before 'cont', when -S is used,
we have a lot of differences. In order, libvirt does something like
this on guest startup:

"qmp_capabilities"
"query-migrate-capabilities"
"migrate-set-capabilities"
"query-chardev"
"qom-list"
"qom-get"
"qom-get"
"query-hotpluggable-cpus"
"query-cpus"
"query-iothreads"
"balloon"
"query-balloon"
"cont"

So --preconfig looks like it cannot be used for anything libvirt currently
does during guest startup. This would force us to use the new set-numa-node
command right at the start, even though this is possibly not a time when
libvirt is actually ready to set the numa node in QEMU. This kind of code
ordering constraint QEMU will put on libvirt is why I really don't like
the idea of having multiple startup phases where you can only use certain
commands in certain phases.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|