Re: [RFC PATCH 0/9] Initial support for machine creation via QMP

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 24 May 2021 19:20:37 +0200
Igor Mammedov <imammedo@redhat.com> wrote:

> On Fri, 14 May 2021 20:32:22 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > Il ven 14 mag 2021, 18:20 Daniel P. Berrangé <berrange@redhat.com> ha
> > scritto:
> >   
> > > My gut feeling though is accel-set would be more logical being done
> > > first, as that also influences the set of features available in other
> > > areas of QEMU configuration. Was there a reason you listed it after
> > > machine-set ?
> > >    
> > 
> > That was also my initial gut feeling, but actually right now the machine
> > influences the accelerator more than the other way round. For example the
> > initialization of the accelerator takes a machine so that for example on
> > x86 the per-architecture KVM knows whether to set up SMM. Also different
> > machines could use different modes for KVM (HV vs PR for ppc), and some
> > machines may not be virtualizable at all so they require TCG.
> > 
> > The host CPU these days is really a virtualization-only synonym for -cpu
> > max, which works for TCG as well. But you're right that x86 CPU flags are
> > dictated by the accelerator rather than the machine, so specifying it in
> > machine-set would be clumsy. On the other hand on ARM it's a bit of both:
> > for KVM it's basically always -cpu host so the accelerator is important;
> > but some machines may have an M profile CPU and some may have an A.  
> and some do not support -cpu/-smp/or rather ignore it and go ahead with hardcoded one/
> 
> 
> > I don't have the sources at hand to check in which phase CPUs are created,
> > but it's definitely after ACCEL_CREATED. Adding a third command
> > cpu-model-set is probably the easiest way to proceed.  
> 
> 
> a naive question,
> why not ditch -cpu completely and instantiate CPUs with
> 
> device_add cpu-foo,flagX=on/off
while writing my another reply to this thread, I realized we might need cpu type
at least for 3 reasons:
 1. It would be hard/impossible to convert every board to create CPUs with
    device_add after board_init(), many boards depend on CPUs being available
    at that time to wire up another devices created at the same time.
 2. If we can postpone cpu creation after board_init() time, user would need
    query-hotpluggable-cpus command to get which CPU type and topology properties
    to use with device_add. (that's what libvirt uses curently)
 3. Recent work on ECPY cpu topology issues, showed that the topology, that board
    generates from -smp might depends on CPU type (we got rid of that eventually but
    I wouldn't rule out possibility in the future).
    
What I would remove from -cpu behavior is resolving cpu-model to CPU type.
QMP command would use only cpu-type so it would be consistent with device_add
which already uses cpu-type, which user gets from query-hotpluggble-cpus.

All legacy cpu-model conversion can be pushed out into CLI compat binary or
up the stack to keep existing deployments running, and new VMs can use cpu types
directly.

Question is how user can query available (for given target/machine/accel) CPU types
using QMP, is there such command already?

> the former is just a kluge for making CLI based -smp initial_nr_cpu/-cpu foo, work.
> I'd move that logic to CLI compat wrapper translating that to a series of device_add calls
> for QMP based QEMU.
> 
> Also I maybe wrong, but I thought that -cpu nowadays does nothing except of translating
> legacy cpu model name to cpu-type and flags to a bunch of '-global', which are applied
> automatically when CPUa are created at board_init() time or later on when device_add is used.
> 
> > Paolo
> > 
> >   
> > > 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 :|
> > >
> > >    
> 
>