From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: damien.hedde@greensocs.com, edgar.iglesias@xilinx.com,
Mirela Grujic <mirela.grujic@greensocs.com>,
mark.burton@greensocs.com, qemu-devel@nongnu.org
Subject: Re: [RFC PATCH 0/9] Initial support for machine creation via QMP
Date: Fri, 14 May 2021 17:20:25 +0100 [thread overview]
Message-ID: <YJ6jSeu3Uz4g6cCK@redhat.com> (raw)
In-Reply-To: <61071d36-b700-8546-c19b-09c4e582bdfe@redhat.com>
On Fri, May 14, 2021 at 06:00:37PM +0200, Paolo Bonzini wrote:
> On 14/05/21 14:48, Mirela Grujic wrote:
> >
> > With our approach, transitioning to the QMP configuration suppose to
> > happen gradually, i.e. we still specify some configuration options via
> > command line. For your approach to be applicable to our use case we
> > would at least need a QMP equivalent for the following:
> >
> > qemu-system-riscv64 \
> > -M sifive_dt \
> > -cpu rv64,i=true,g=false,m=true,a=true,f=true,d=true,c=true,s=false,u=false,x-b=true,pmp=true,mmu=false,num-pmp-regions=8
> > \
> > -smp 1 \
> > -device ...
> >
> > AFAIU from the materials you shared, we would need to add -cpu and
> > -device, but I don't see any reason why we wouldn't do this.
>
> -cpu is indeed the big one that I had not looked at so far, while -device
> should be mostly covered by the existing device_add command.
>
> One possibility for -cpu is to make it an argument of machine-set too. For
> example the above would be
>
> { 'execute': 'machine-set', arguments: {
> 'type': 'sifive_dt',
> 'smp': { 'cpus': 1 },
> 'cpu': { 'model': 'rv64', 'i': true, 'g': false, ... }
> }
CPUs are a little complex because they have association with both machine
types and accelerator backends. You have 'accel-set' being issued after
'machine-set', but the 'host' CPU model is only valid if you have set
the KVM accelerator, not TCG.
It is desirable that you get an error report about bad CPU at the time
you specify the CPU config, rather than have that error delayed to when
a later command runs and invalidates your CPU choice.
This is a long winded way of saying either 'accel-set' should be
run before 'machine-set', or 'cpu' would have to be set as its own
command or as part of 'accel-set'.
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 ?
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 :|
next prev parent reply other threads:[~2021-05-14 16:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-13 8:25 [RFC PATCH 0/9] Initial support for machine creation via QMP Mirela Grujic
2021-05-13 8:25 ` [RFC PATCH 1/9] vl: Allow finer control in advancing machine through phases Mirela Grujic
2021-05-13 8:25 ` [RFC PATCH 2/9] replace machine phase_check with machine_is_initialized/ready calls Mirela Grujic
2021-05-13 17:46 ` Paolo Bonzini
2021-05-14 13:13 ` Mirela Grujic
2021-05-14 21:14 ` Paolo Bonzini
2021-06-07 16:03 ` Eric Blake
2021-05-13 8:25 ` [RFC PATCH 3/9] rename MachineInitPhase enumeration constants Mirela Grujic
2021-05-13 8:25 ` [RFC PATCH 4/9] qapi: Implement 'query-machine-phase' command Mirela Grujic
2021-05-13 17:44 ` Paolo Bonzini
2021-05-19 15:43 ` Daniel P. Berrangé
2021-05-13 8:25 ` [RFC PATCH 5/9] qapi: Implement 'next-machine-phase' command Mirela Grujic
2021-06-04 14:25 ` Eric Blake
2021-06-05 14:40 ` Paolo Bonzini
2021-05-13 8:25 ` [RFC PATCH 6/9] qapi: Implement 'advance-machine-phase' command Mirela Grujic
2021-05-19 15:37 ` Kevin Wolf
2021-05-13 8:25 ` [RFC PATCH 7/9] qdev-monitor: Restructure and fix the check for command availability Mirela Grujic
2021-05-13 17:43 ` Paolo Bonzini
2021-05-14 13:00 ` Mirela Grujic
2021-05-13 8:25 ` [RFC PATCH 8/9] qapi: Introduce 'allow-init-config' option Mirela Grujic
2021-05-13 8:25 ` [RFC PATCH 9/9] qapi: Allow some commands to be executed in machine 'initialized' phase Mirela Grujic
2021-05-13 17:52 ` [RFC PATCH 0/9] Initial support for machine creation via QMP Paolo Bonzini
2021-05-14 12:48 ` Mirela Grujic
2021-05-14 16:00 ` Paolo Bonzini
2021-05-14 16:20 ` Daniel P. Berrangé [this message]
2021-05-14 18:32 ` Paolo Bonzini
2021-05-24 17:20 ` Igor Mammedov
2021-05-24 19:05 ` Igor Mammedov
2021-05-21 11:32 ` Markus Armbruster
2021-05-21 17:02 ` Paolo Bonzini
2021-05-21 14:06 ` Mirela Grujic
2021-05-21 16:57 ` Paolo Bonzini
2021-05-24 18:27 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJ6jSeu3Uz4g6cCK@redhat.com \
--to=berrange@redhat.com \
--cc=damien.hedde@greensocs.com \
--cc=edgar.iglesias@xilinx.com \
--cc=mark.burton@greensocs.com \
--cc=mirela.grujic@greensocs.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).