DRAFT-DRAFT: Cpu profiles #1: CPUID feature restriction by olivereanderson · Pull Request #9 · cyberus-technology/cloud-hypervisor

olivereanderson · 2025-07-31T19:18:45Z

This is the first part of a (presumably) three part effort to introduce CPU profiles, which are largely analogous to QEMU's CPU Models.

In short the motivation for this feature is to enable live migrations between hosts that share a reasonably large set of features (identified with a CPU profile). Note that this MR is only concerned with the restriction of CPUID entries for virtual CPUs, but MSR (model specific register) configuration is also necessary for migration compatibility. The latter will be addressed in part 2. While the final part three will just be about updating the existing end user documentation.

Some arguments for the current approach, from a user's perspective, can be found in the following under specified RFC.

Steps to undraft

Should it be a hard error to attempt to create a VM on a host that does not support all the features declared for a given CPU profile?
Write multiple integration tests using QEMU.
Confirm my suspicion that it is enough to perform the restriction in arch::generate_common_cpuid (in other words that it does not need to be done elsewhere in the code base as well).
Figure out if we should structure some of the code differently (what goes in which module).
Figure out if we are happy with the current macro usage. The macro introduced here can either be improved, or we may prefer defining the feature flag sets in terms of the "official" lowercase cpu id feature names. The alternative way I had in mind is demonstrated here. There are also very valid reasons not to use a macro at all here.
Fix git state and the final commit message.

olivereanderson · 2025-08-06T15:56:47Z

I see this is quite a bit more involved than I initially thought, but I am making good progress. Will update the MR in the coming days.

Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.33.1 to 1.34.0. - [Release notes](https://github.com/crate-ci/typos/releases) - [Changelog](https://github.com/crate-ci/typos/blob/master/CHANGELOG.md) - [Commits](crate-ci/typos@v1.33.1...v1.34.0) --- updated-dependencies: - dependency-name: crate-ci/typos dependency-version: 1.34.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>

When invoking the script chown shows a warning. chown: warning: '.' should be ':': ‘1000.1000’ From `info coreutils 'chown invocation'`. Some older scripts may still use ‘.’ in place of the ‘:’ separator. POSIX 1003.1-2001 (*note Standards conformance::) does not require support for that, but for backward compatibility GNU ‘chown’ supports ‘.’ so long as no ambiguity results, although it issues a warning and support may be removed in future versions. New scripts should avoid the use of ‘.’ because it is not portable, and because it has undesirable results if the entire OWNER‘.’GROUP happens to identify a user whose name contains ‘.’. Signed-off-by: Wei Liu <liuwe@microsoft.com>

…sters as fields

olivereanderson · 2025-08-11T13:16:51Z


 # Ensure that we can access this device
-sudo chown "$UID.$UID" "$tapdevice"
+sudo chown "$UID:$UID" "$tapdevice"


No idea how this change got here. I have not touched that.

seems like your branch has the wrong base; why not drop the first two commits and force-push?

olivereanderson · 2025-08-11T15:06:21Z

      - uses: actions/checkout@v4
      # Executes "typos ."
-      - uses: crate-ci/typos@v1.33.1
+      - uses: crate-ci/typos@v1.34.0


Also not my doing.

Should fix this before merging.

olivereanderson · 2025-08-15T10:20:00Z

+pub struct CpuIdFeatureFlags {
+    pub edx_1: CpuIdEntryRegister<1, 0, { CpuidReg::EDX as u8 }>,
+    pub ecx_1: CpuIdEntryRegister<1, 0, { CpuidReg::ECX as u8 }>,
+    pub ebx_7_0: CpuIdEntryRegister<7, 0, { CpuidReg::EBX as u8 }>,
+    pub ecx_7_0: CpuIdEntryRegister<7, 0, { CpuidReg::ECX as u8 }>,
+    pub edx_7_0: CpuIdEntryRegister<7, 0, { CpuidReg::EDX as u8 }>,
+    pub eax_7_1: CpuIdEntryRegister<7, 1, { CpuidReg::EAX as u8 }>,
+    pub ecx_7_1: CpuIdEntryRegister<7, 1, { CpuidReg::ECX as u8 }>,
+    pub edx_7_1: CpuIdEntryRegister<7, 1, { CpuidReg::EDX as u8 }>,
+    pub edx_7_2: CpuIdEntryRegister<7, 2, { CpuidReg::EDX as u8 }>,
+    pub eax_0dh_1: CpuIdEntryRegister<0xd, 1, { CpuidReg::EAX as u8 }>,
+    pub ecx_14h: CpuIdEntryRegister<0x14, 0, { CpuidReg::ECX as u8 }>,
+    pub ecx_24h_1: CpuIdEntryRegister<0x24, 1, { CpuidReg::ECX as u8 }>,
+    pub edx_8000_0001h: CpuIdEntryRegister<0x8000_0001, 0, { CpuidReg::EDX as u8 }>,
+    pub ecx_8000_0001h: CpuIdEntryRegister<0x8000_0001, 0, { CpuidReg::ECX as u8 }>,
+    pub edx_8000_0007h: CpuIdEntryRegister<0x8000_0007, 0, { CpuidReg::EDX as u8 }>,
+    pub ebx_8000_0008h: CpuIdEntryRegister<0x8000_0008, 0, { CpuidReg::EBX as u8 }>,
+    /// FEAT_SVM in QEMU
+    pub edx_8000_000ah: CpuIdEntryRegister<0x8000_000A, 0, { CpuidReg::EDX as u8 }>,
+    pub eax_8000_0021h: CpuIdEntryRegister<0x8000_0021, 0, { CpuidReg::EAX as u8 }>,
+}


After talking to @snue I think we can avoid this struct and just inline it's restrict method where it is needed. This way we can avoid naming all the fields in this struct (which is kind of duplicate work as the names are reflected in the const generic parameters) and instead just call restrict on each of the relevant CpuIdEntryRegister types directly.

phip1611 · 2025-08-19T11:00:50Z

+pub(super) struct CascadeLakeServerV1CpuIdFeatures {
+    edx_1: CpuIdFeatureFlags<1, 0, { CpuidReg::EDX as u8 }>,
+    ecx_1: CpuIdFeatureFlags<1, 0, { CpuidReg::ECX as u8 }>,
+    edx_8000_0001h: CpuIdFeatureFlags<0x8000_0001, 0, { CpuidReg::EDX as u8 }>,


I don't know x86 cpuid well: why does this value look so different to the others?

phip1611 · 2025-08-19T11:05:53Z

+    #[default]
+    Host,
+    #[cfg(target_arch = "x86_64")]
+    CascadeLakeServerV1,


what is V1, and what is V2 then?

olivereanderson self-assigned this Jul 31, 2025

olivereanderson changed the title ~~Cpu profiles #1: CPUID feature restriction~~ DRAFT-DRAFT: Cpu profiles #1: CPUID feature restriction Jul 31, 2025

olivereanderson commented Aug 1, 2025

View reviewed changes

Comment thread arch/src/x86_64/mod.rs Outdated

olivereanderson commented Aug 1, 2025

View reviewed changes

Comment thread arch/src/x86_64/mod.rs Outdated

olivereanderson commented Aug 1, 2025

View reviewed changes

Comment thread arch/src/x86_64/mod.rs Outdated

dependabot Bot and others added 23 commits August 11, 2025 15:14

Start manual implementation of CPUID feature flag values

51d16ab

Add Feature flags with macros

3b9962f

constructor

71bcaad

Intersect feature flags

3dd61f6

Move CpuProfile into arch/src/lib.rs

659b194

Make it compile with warnings

bf5955c

Implement the restriction, improve documentation and some minor cleanup

f48b1e7

Adjust documentation

bce9f29

Fix missing conditional compilation

199adc3

Fix name

cc2e355

Include missing field

4a23b61

Shorten macro

0f75b3e

Simplify macro further

618f169

Drop guard early

8218816

Make inner value public

96ffe84

Rename CpuIdFeatureFlags

89a7ab3

Refactor: Less structs. Use one complete struct with all feature regi…

389f5f6

…sters as fields

Refactoring

1964fbf

Add TODO comment for AMD duplicates

2e50d2c

More associated constants

f68a9d9

Change macro to be more doc friendly

5c1ae50

olivereanderson force-pushed the oanderson/cpu-profiles branch from f0461da to 5c1ae50 Compare August 11, 2025 13:14

olivereanderson changed the base branch from main to gardenlinux August 11, 2025 13:14

olivereanderson commented Aug 11, 2025

View reviewed changes

Improve logs and add more comments

b08bcc2

olivereanderson commented Aug 15, 2025

View reviewed changes