From: Andrea Bolognani <abologna@redhat.com>
To: "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: Wed, 11 Apr 2018 17:35:55 +0200 [thread overview]
Message-ID: <1523460955.2942.5.camel@redhat.com> (raw)
In-Reply-To: <20180410085200.GD5155@redhat.com>
On Tue, 2018-04-10 at 09:52 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 10, 2018 at 09:41:33AM +0200, Andrea Bolognani wrote:
> > 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.
>
> Libvirt uses versioned machine types and does not specify -cpu unless the
> user has added <cpu> to their XML. IOW libvirt assumes the default CPU
> model is stable because that's what QEMU has promised in the past.
Hm, you have a point.
I wonder how well that works in practice, though. I started a guest
with no <cpu> element on my laptop and it ended up having
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : QEMU Virtual CPU version 2.5+
stepping : 3
which I guess translates to the qemu64 CPU model, based on the
description. I have verified the -cpu option is not present on the
command line.
The name seems to imply that if I were using a QEMU release older
than 2.5 I would get a different CPU model, but maybe the stable CPU
guarantee you mention is just a fairly recent development.
I also know that ppc64 performs some trickery if you don't specify a
CPU model, so by default you get a behavior which is pretty close to
using -cpu host.
Basically I'm wondering how reasonable it is to expect a migratable
machine and a stable guest ABI when relying on QEMU defaults instead
of explicitly picking a CPU model.
--
Andrea Bolognani / Red Hat / Virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Andrea Bolognani <abologna@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Wei Huang <wei@redhat.com>,
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: Wed, 11 Apr 2018 17:35:55 +0200 [thread overview]
Message-ID: <1523460955.2942.5.camel@redhat.com> (raw)
In-Reply-To: <20180410085200.GD5155@redhat.com>
On Tue, 2018-04-10 at 09:52 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 10, 2018 at 09:41:33AM +0200, Andrea Bolognani wrote:
> > 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.
>
> Libvirt uses versioned machine types and does not specify -cpu unless the
> user has added <cpu> to their XML. IOW libvirt assumes the default CPU
> model is stable because that's what QEMU has promised in the past.
Hm, you have a point.
I wonder how well that works in practice, though. I started a guest
with no <cpu> element on my laptop and it ended up having
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : QEMU Virtual CPU version 2.5+
stepping : 3
which I guess translates to the qemu64 CPU model, based on the
description. I have verified the -cpu option is not present on the
command line.
The name seems to imply that if I were using a QEMU release older
than 2.5 I would get a different CPU model, but maybe the stable CPU
guarantee you mention is just a fairly recent development.
I also know that ppc64 performs some trickery if you don't specify a
CPU model, so by default you get a behavior which is pretty close to
using -cpu host.
Basically I'm wondering how reasonable it is to expect a migratable
machine and a stable guest ABI when relying on QEMU defaults instead
of explicitly picking a CPU model.
--
Andrea Bolognani / Red Hat / Virtualization
next prev parent reply other threads:[~2018-04-11 15:36 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 ` [Qemu-arm] " Andrea Bolognani
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 ` Andrea Bolognani [this message]
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=1523460955.2942.5.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 \
/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.