All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>
Subject: Re: x86 CPU properties "family", "model", "stepping", "tsc-freq"
Date: Wed, 9 Oct 2024 12:35:26 +0100	[thread overview]
Message-ID: <ZwZqfniI9UlHHXVG@redhat.com> (raw)
In-Reply-To: <87wmihr14b.fsf@pond.sub.org>

On Wed, Oct 09, 2024 at 01:01:40PM +0200, Markus Armbruster wrote:
> QOM properties serve several purposes: initial configuration (external
> interface), run time control and monitoring (external interface), and
> internal purposes like versioning.  Which purpose(s) a property serves
> is often unclear.
> 
> The x86 CPU properties "family", "model", and "stepping" are used
> internally; see target/i386/cpu.c and hw/i386/pc.c.  I figure changing
> them at run time makes no sense.  What about configuration?  Can the
> user set arbitrary CPU properties?  If yes, are these properties meant
> to be set by the user?

The named CPU models have associated family/model/stepping (FMS),
and the string "model-i"' info defined against them, that match
the some arbitrary choice of silicon.

QEMU doesn't support all possible values though. For example,
we've seen real Skylake-Server CPUs with stepping in the range
0-4, but QEMU always reports 4 for stepping, so altering that
is potentially interesting if wanting to check guest behaviour
with a very specific FMS value.

More generally QEMU doesn't support every possible CPU model
that exists.

You can invent entirely new CPUs by turning on/off individual
CPUID feature flags, along with setting the FMS and the model-id
string.

 $ ./make-tiny-image.py --run  "cat /proc/cpuinfo"
  6.9.9-200.fc40.x86_64

 $ qemu-system-x86_64  -nodefaults -display none -serial stdio -accel kvm -m 1024 -kernel /lib/modules/6.10.8-200.fc40.x86_64/vmlinuz -initrd tiny-initrd.img  -append 'console=ttyS0 quiet' -cpu Skylake-Server | grep -E '(model|family|stepping)'
cpu family	: 6
model		: 85
model name	: Intel Xeon Processor (Skylake)
stepping	: 4

Invent my own CPU...

 $ qemu-system-x86_64  -nodefaults -display none -serial stdio -accel kvm -m 1024 -kernel /lib/modules/6.10.8-200.fc40.x86_64/vmlinuz -initrd tiny-initrd.img  -append 'console=ttyS0 quiet' -cpu Skylake-Server,family=13,model=42,model-id="Fish Food",stepping=3 | grep -E '(model|family|stepping)'
 cpu family	: 13
 model		: 42
 model name	: Fish Food
 stepping	: 1

Whether or not the requested FMS & model-id choices actually make
conceptual sense is upto the user to figure out :-)

Setting these values is certainly niche, but still valid IMHO.

> Property "tsc-freq" seems not to be used internally.  I figure changing
> it at run time makes no sense.  Looks like it is be meant to be set by
> the user: x86_cpu_parse_featurestr() seems to parse it from the argument
> of -cpu.  Correct?  Note that -cpu help doesn't mention it.

"tsc-freq" is a back compat alias for 'tsc-frequency' AFAICT, and
we need the latter if you want to guarantee fixed TSC freq across
migration. eg commit 561dbb41b1d752098249128d8462aaadc56fd15d

With 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 :|



  reply	other threads:[~2024-10-09 11:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09 11:01 x86 CPU properties "family", "model", "stepping", "tsc-freq" Markus Armbruster
2024-10-09 11:35 ` Daniel P. Berrangé [this message]
2024-10-09 11:47   ` Markus Armbruster
2024-10-09 13:44   ` Markus Armbruster
2024-10-09 13:47     ` 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=ZwZqfniI9UlHHXVG@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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.