All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.