From: Andrea Bolognani <abologna@redhat.com>
To: "Wei Huang" <wei@redhat.com>, "Daniel P. Berrangé" <berrange@redhat.com>
Cc: peter.maydell@linaro.org, drjones@redhat.com,
qemu-arm@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH 1/1] mach-virt: Change default cpu and gic-version setting to "max"
Date: Tue, 10 Apr 2018 09:41:33 +0200 [thread overview]
Message-ID: <1523346093.16671.23.camel@redhat.com> (raw)
In-Reply-To: <6bb12858-3b4e-e92f-93ea-b8708c8be870@redhat.com>
On Mon, 2018-04-09 at 11:29 -0500, Wei Huang wrote:
> > > Running mach-virt machine types (i.e. "-M virt") on different systems can
> > > result in various misleading warnings if -cpu and/or gic-version not specified.
> > > For KVM, this can be solved mostly by using "host" type. But the "host" type
> > > doesn't work for TCG. Compared with "host", the "max" type not only supports
> > > auto detection under KVM mode, but also works with TCG. So this patch set
> > > "max" as the default types for both -cpu and gic-version.
> >
> > Hmm, generally we aim for the config provided by a machine type to be stable
> > across QEMU versions.
>
> I understand this principle. But in reality, under KVM mode, the default
> config most time doesn't work. If end users specify cpu type manually,
> it still doesn't work because the host CPU is vendor-specific design
> (e.g. "cortex-a57" doesn't work on QCOM's machine). So we end up with
> using "-cpu host" all the time. My argument for this patch is that "-cpu
> max" isn't worse than "-cpu host".
I figure the people not explicitly specifying a CPU model on the
command line will probably also use '-M virt' instead of versioned
machine types, which means they will get a different guest behavior
after upgrading QEMU regardless.
Defaulting to 'max' for '-cpu' and 'gic-version' makes it convenient
to quickly and concisely start a guest; if you care about guest ABI
at all, then you are already specifying everything explicitly on the
command line instead of relying on defaults - or using libvirt ;)
--
Andrea Bolognani / Red Hat / Virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Andrea Bolognani <abologna@redhat.com>
To: "Wei Huang" <wei@redhat.com>, "Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, peter.maydell@linaro.org,
drjones@redhat.com, qemu-arm@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/1] mach-virt: Change default cpu and gic-version setting to "max"
Date: Tue, 10 Apr 2018 09:41:33 +0200 [thread overview]
Message-ID: <1523346093.16671.23.camel@redhat.com> (raw)
In-Reply-To: <6bb12858-3b4e-e92f-93ea-b8708c8be870@redhat.com>
On Mon, 2018-04-09 at 11:29 -0500, Wei Huang wrote:
> > > Running mach-virt machine types (i.e. "-M virt") on different systems can
> > > result in various misleading warnings if -cpu and/or gic-version not specified.
> > > For KVM, this can be solved mostly by using "host" type. But the "host" type
> > > doesn't work for TCG. Compared with "host", the "max" type not only supports
> > > auto detection under KVM mode, but also works with TCG. So this patch set
> > > "max" as the default types for both -cpu and gic-version.
> >
> > Hmm, generally we aim for the config provided by a machine type to be stable
> > across QEMU versions.
>
> I understand this principle. But in reality, under KVM mode, the default
> config most time doesn't work. If end users specify cpu type manually,
> it still doesn't work because the host CPU is vendor-specific design
> (e.g. "cortex-a57" doesn't work on QCOM's machine). So we end up with
> using "-cpu host" all the time. My argument for this patch is that "-cpu
> max" isn't worse than "-cpu host".
I figure the people not explicitly specifying a CPU model on the
command line will probably also use '-M virt' instead of versioned
machine types, which means they will get a different guest behavior
after upgrading QEMU regardless.
Defaulting to 'max' for '-cpu' and 'gic-version' makes it convenient
to quickly and concisely start a guest; if you care about guest ABI
at all, then you are already specifying everything explicitly on the
command line instead of relying on defaults - or using libvirt ;)
--
Andrea Bolognani / Red Hat / Virtualization
next prev parent reply other threads:[~2018-04-10 7:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 15:49 [Qemu-arm] [PATCH 1/1] mach-virt: Change default cpu and gic-version setting to "max" Wei Huang
2018-04-09 15:49 ` [Qemu-devel] " Wei Huang
2018-04-09 15:55 ` [Qemu-arm] " Peter Maydell
2018-04-09 15:55 ` [Qemu-devel] " Peter Maydell
2018-04-09 16:42 ` [Qemu-arm] " Wei Huang
2018-04-09 16:42 ` Wei Huang
2018-04-09 15:56 ` [Qemu-arm] " Daniel P. Berrangé
2018-04-09 15:56 ` Daniel P. Berrangé
2018-04-09 16:29 ` [Qemu-arm] " Wei Huang
2018-04-09 16:29 ` Wei Huang
2018-04-10 7:41 ` Andrea Bolognani [this message]
2018-04-10 7:41 ` Andrea Bolognani
2018-04-10 8:52 ` [Qemu-arm] " Daniel P. Berrangé
2018-04-10 8:52 ` Daniel P. Berrangé
2018-04-11 15:35 ` [Qemu-arm] " Andrea Bolognani
2018-04-11 15:35 ` Andrea Bolognani
2018-04-12 8:19 ` [Qemu-arm] " Daniel P. Berrangé
2018-04-12 8:19 ` Daniel P. Berrangé
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=1523346093.16671.23.camel@redhat.com \
--to=abologna@redhat.com \
--cc=berrange@redhat.com \
--cc=drjones@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wei@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.