qemu-devel
[Top][All Lists]
Advanced

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

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


From: Igor Mammedov
Subject: Re: [RFC PATCH 0/9] Initial support for machine creation via QMP
Date: Mon, 24 May 2021 20:27:50 +0200

On Fri, 21 May 2021 18:57:36 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 21/05/21 16:06, Mirela Grujic wrote:
> >>
> >> PHASE_NO_MACHINE
> >>    -> machine-set -> PHASE_MACHINE_CREATED ->
> >>    -> accel-set -> PHASE_ACCEL_CREATED -> PHASE_MACHINE_INITIALIZED ->  
> > 
> > 
> > My understanding is that an equivalent of previously supported 
> > 'preconfig' state is PHASE_ACCEL_CREATED, from the perspective of the 
> > QMP configuration that Igor implemented. In other words, I believe that 
> > when -preconfig CLI option was passed, QEMU was waiting for the QMP 
> > configuration in PHASE_ACCEL_CREATED phase. Now, if accel-set advances 
> > the machine directly to PHASE_MACHINE_INITIALIZED, there will be no 
> > chance to configure what Igor did with -preconfig.  
> 
> Right, that was only NUMA.  I have to check, but I think it can be moved 
> to PHASE_MACHINE_CREATED.
Dependency for NUMA were:
  1: -smp/-cpu being parsed before set_numa_options QMP command is called
        it's necessary to for machine being able to provide topology for
        given -smp combination.

        -cpu is not must have dependency (currently), it was just conveniently
        available when building topology in possible_cpu_arch_ids(), setting
        cpu-type there could be deffered to the later time (actual user for
        CPU type is QMP command query-hotpluggable-cpus, so that user could know
        what cpu type and what properties to use with device_add at hot-add 
time).

  2: memory backends depended on accel (TCG)
     (I think, Paolo has removed that dependency)


> Apart from that, if we add a third command for the CPU model, that third 
> command would run from PHASE_ACCEL_CREATED so the pre-existing preconfig 
> state would be accessible.
> 
> Paolo
> 
> > Is this something you don't want to support anymore, or it can be 
> > configured in another way? Or is this something that we haven't thought 
> > of yet, but we should?  
> 
> 




reply via email to

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