From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Andrea Bolognani <abologna@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: Thu, 12 Apr 2018 09:19:54 +0100 [thread overview]
Message-ID: <20180412081954.GB31024@redhat.com> (raw)
In-Reply-To: <1523460955.2942.5.camel@redhat.com>
On Wed, Apr 11, 2018 at 05:35:55PM +0200, Andrea Bolognani wrote:
> 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.
That model ID string is tied to the machine type, so it is stable. Older
machine types use PC_CPU_MODEL_IDS() in pc.h to ensure they have not
changed.
> 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.
Provided you have picked a versioned machine type, it is expected that all
other defaults are stable, and that includes CPU models.
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 :|
WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Andrea Bolognani <abologna@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: Thu, 12 Apr 2018 09:19:54 +0100 [thread overview]
Message-ID: <20180412081954.GB31024@redhat.com> (raw)
In-Reply-To: <1523460955.2942.5.camel@redhat.com>
On Wed, Apr 11, 2018 at 05:35:55PM +0200, Andrea Bolognani wrote:
> 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.
That model ID string is tied to the machine type, so it is stable. Older
machine types use PC_CPU_MODEL_IDS() in pc.h to ensure they have not
changed.
> 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.
Provided you have picked a versioned machine type, it is expected that all
other defaults are stable, and that includes CPU models.
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:[~2018-04-12 8:20 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 ` [Qemu-arm] " Andrea Bolognani
2018-04-11 15:35 ` Andrea Bolognani
2018-04-12 8:19 ` Daniel P. Berrangé [this message]
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=20180412081954.GB31024@redhat.com \
--to=berrange@redhat.com \
--cc=abologna@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.