qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max
Date: Mon, 22 Jul 2019 12:40:46 +0100	[thread overview]
Message-ID: <CAFEAcA_uOX9qkrwRASAaxOfTms9SsQMEyhJ0XwYFiFPVtEnqkw@mail.gmail.com> (raw)
In-Reply-To: <20190722111914.28574-1-alex.bennee@linaro.org>

On Mon, 22 Jul 2019 at 12:19, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> While most features are now detected by probing the ID_* registers
> kernels can (and do) use MIDR_EL1 for working out of they have to
> apply errata. This can trip up warnings in the kernel as it tries to
> work out if it should apply workarounds to features that don't
> actually exist in the reported CPU type.
>
> Avoid this problem by synthesising our own MIDR value using the
> reserved value of 0 for the implementer and encoding the moving feast
> that is the QEMU version string into the other fields.

Exposing the QEMU_VERSION_* information to the guest is
usually not a good plan. For instance it means that the
MIDR will mysteriously change if you save a VM on one
version of QEMU and restore it on another. We went through
a while back carefully removing places where we'd exposed
the version number to the guest (have a look at the
qemu_hw_version() stuff which has to jump through hoops
so that old versioned machines like pc-1.5 report the
old "1.5" version number, and any QEMU 2.5 and above
now reports "2.5+"...)

thanks
-- PMM


  reply	other threads:[~2019-07-22 11:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 11:19 [Qemu-devel] [RFC PATCH for 4.2] target/arm: generate a custom MIDR for -cpu max Alex Bennée
2019-07-22 11:40 ` Peter Maydell [this message]
2019-07-22 11:57   ` Alex Bennée

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=CAFEAcA_uOX9qkrwRASAaxOfTms9SsQMEyhJ0XwYFiFPVtEnqkw@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=alex.bennee@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 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).