x86 CPU properties "family", "model", "stepping", "tsc-freq"

x86 CPU properties "family", "model", "stepping", "tsc-freq"

[Markus Armbruster]

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?

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.

Re: x86 CPU properties "family", "model", "stepping", "tsc-freq"

[Daniel P. Berrangé]

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

Re: x86 CPU properties "family", "model", "stepping", "tsc-freq"

[Markus Armbruster]

Thank you!

Re: x86 CPU properties "family", "model", "stepping", "tsc-freq"

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> 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.

[...]

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

Looking more closely...

"tsc-freq" wraps around "tsc-frequency" except the value is converted
with qemu_strtosz_metric().

"tsc-frequency" accepts values between 0 and INT64_MAX.  The unit is Hz.
However, the frequency is internally stored in kHz, in CPUArchState
member tsc_khz, and the conversion from the value "tsc-frequency"
silently truncates.  Ugh!  See x86_cpuid_set_tsc_freq().

kvm_arch_set_tsc_khz() passes the kHz value to the kernel like this:

    kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz)

I believe the kernel code consuming the value is in arch/x86/kvm/x86.c's
kvm_arch_vcpu_ioctl().  It appears to silently truncate the value to 32
bit unsigned:

	case KVM_SET_TSC_KHZ: {
		u32 user_tsc_khz;

		r = -EINVAL;
--->		user_tsc_khz = (u32)arg;

		if (kvm_caps.has_tsc_control &&
		    user_tsc_khz >= kvm_caps.max_guest_tsc_khz)
			goto out;

		if (user_tsc_khz == 0)
			user_tsc_khz = tsc_khz;

		if (!kvm_set_tsc_khz(vcpu, user_tsc_khz))
			r = 0;

		goto out;
	}

Ugh again!

Should we reject values exceeding UINT32_MAX kHz in QEMU?

Re: x86 CPU properties "family", "model", "stepping", "tsc-freq"

[Daniel P. Berrangé]

On Wed, Oct 09, 2024 at 03:44:25PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > 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.
> 
> [...]
> 
> >> 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
> 
> Looking more closely...
> 
> "tsc-freq" wraps around "tsc-frequency" except the value is converted
> with qemu_strtosz_metric().
> 
> "tsc-frequency" accepts values between 0 and INT64_MAX.  The unit is Hz.
> However, the frequency is internally stored in kHz, in CPUArchState
> member tsc_khz, and the conversion from the value "tsc-frequency"
> silently truncates.  Ugh!  See x86_cpuid_set_tsc_freq().
> 
> kvm_arch_set_tsc_khz() passes the kHz value to the kernel like this:
> 
>     kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz)
> 
> I believe the kernel code consuming the value is in arch/x86/kvm/x86.c's
> kvm_arch_vcpu_ioctl().  It appears to silently truncate the value to 32
> bit unsigned:
> 
> 	case KVM_SET_TSC_KHZ: {
> 		u32 user_tsc_khz;
> 
> 		r = -EINVAL;
> --->		user_tsc_khz = (u32)arg;
> 
> 		if (kvm_caps.has_tsc_control &&
> 		    user_tsc_khz >= kvm_caps.max_guest_tsc_khz)
> 			goto out;
> 
> 		if (user_tsc_khz == 0)
> 			user_tsc_khz = tsc_khz;
> 
> 		if (!kvm_set_tsc_khz(vcpu, user_tsc_khz))
> 			r = 0;
> 
> 		goto out;
> 	}
> 
> Ugh again!
> 
> Should we reject values exceeding UINT32_MAX kHz in QEMU?

Sounds like a reasonable idea to me, as I don't think it is very likely
that someone is passing a number greater than UINT32_MAX and relying
on truncation.


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