Register EDX of CPUID leaf 0x7 sub-leaf 0x2 (Structured Extended Feature
Enumeration Sub-leaf) is currently not checked, but it should be.
KVM supports several of the features enumerated by this value when they
are supported by the host such as Intel PSFD, IPRED_CTRL, RRSBA_CTRL
and more.
The migration destination needs to support any such feature exposed to
the guest from the migration source.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Register EDX of CPUID leaf 0x7 sub-leaf 0x1 (Structured Extended Feature
Enumeration Sub-leaf) is currently not checked, but it should be.
KVM supports several of the features enumerated by this value when they
are supported by the host, such as AVX-VNNI-INT8, AMX-COMPLEX, AVX10
and more.
The migration destination needs to support any such feature exposed to
the guest from the migration source.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Register ECX of CPUID leaf 0x7 sub-leaf 0x1 (Structured Extended Feature
Enumeration Sub-leaf) is currently not checked, but it should be.
KVM exposes bit 5 (MSR_IMM: the immediate forms of the RDMSR and WRMSR
instructions) when the host does.
Live migrating from a source that supports MSR_IMM to a destination
that does not is not safe.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
We introduce a function somewhat analogous to `generate_common_cpuid`,
except that it is only relevant for CPU profiles.
This function is more "high level" than the
CpuProfile::required_msr_updates method and is intended to be called
from the vmm crate.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
In order to safely apply CPU profiles we need to ensure that the host's
feature MSRs that are permitted by the CPU profile are also compatible
with the values the CPU profile dictates.
KVM_SET_MSRs takes care of checking compatibility for most feature MSRs
on both Intel and AMD CPUs that we will permit CPU profiles to have
(more on this in the upcoming CPU profile generation tool PRs),
but there is one exception.
Userspace may set whatever value for the Intel exclusive
IA32_ARCH_CAPABILITIES MSR without receiving any complaints from KVM.
We thus introduce our own compatibility check for
IA32_ARCH_CAPABILITIES.
One might even argue that KVM_SET_MSRs is called relatively late when
creating or receiving a VM and that it would be preferable to have
compatibility checks for all permitted feature MSRs run earlier. This
would also mean more informative debug logs.
We argue however that those additional checks would lead to too much
code that is not strictly necessary which is why we decided against
doing that in this patch set.
The code introduced here is only intended to be used with CPU profiles
at this point in time, but it is written in such a way that it could
also be used for MSR compatibility checks between a migration source
and destination (when the Host profile is in use) should that be
desired in the future.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
We introduce a method on the CpuProfile enum that computes the required
MSR related updates in order to be compatible with the CPU profile.
The output of this function describes the feature MSRs that need to be
set and the snapshottable MSRs that are compatible with the chosen CPU
profile. The former provides the guest information about CPU features
(that are not obtainable from inspecting CPUID) while the latter is
used to ensure that MSRs that are incompatible with the CPU profile
are not set upon snapshot/restore.
These will be utilized in the vmm crate in a follow up commit.
We expect the hypervisor to take care of checking compatibility of the
feature MSRs when they are set. IA32_ARCH_CAPABILITIES is a known
exception however which we introduce our own checks for in a follow
up commit.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
When Cloud hypervisor has not been configured for (KVM) Hyper-V we want
to adapt the CPU profiles not to require existence of Hyper-V related
MSRs.
The first step introduced here is to create a list of such MSRs.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
We introduce a type describing MSR adjustments associated with a
CPU profile.
The upcoming CPU profile generation tool will serialize instances of
this struct when generating a CPU profile.
A follow up PR will take care of filling out the currently stubbed
`msr_data` method.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
CPU Profiles will be serialized to JSON by the upcoming CPU Profile
generation tool and we want MSRs to be serialized as hex strings.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
We create 64-bit analogues of the already existing hex (de-)serializer
helper functions for the 32-bit case.
These are necessary because the CPU profile needs associated data
describing how to adjust feature MSRs whose values are 64-bits.
In this case we prefer some small amount of code duplication over
macros and/or traits since we do not expect the need for further
variants of these helpers.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Whenever a CPU profile is selected there will be feature MSRs that need
to be set when the CPU is configured.
We thus adapt the boot_msr_entries method to include the feature MSRs
that are passed to the vCPU upon construction.
Since KVM applies compatibility checks for all feature MSRs (except
IA32_ARCH_CAPABILITIES) we can only proceed if all MSR boot entries
are successfully set upon vCPU configuration.
This new check also applies to the regular boot entries when the host
profile is selected (the default), but that is arguably an improvement
in terms of correctness.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
create_cpu_nodes() emits one shared-L3 cache node per package when the
host reports a shared L3, but names every node with the constant
"l3-cache0". For a guest topology with packages >= 2 the generated
device tree carries the same name siblings.
Fixes: 5857d4851
Assisted-by: Claude:Opus-4.8 (1M context)
Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>
vm-memory 0.18 has renamed GuestMemory to GuestMemoryBackend, and made
GuestMemory refer to something less specific. For simplicity, we keep
using GuestMemoryBackend (formerly GuestMemory) everywhere for now. We
can adjust bounds to be less specific later if we find ourselves needing
the newly enabled flexibility.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Signed-off-by: Rob Bradford <rbradford@meta.com>
Both arch/src/aarch64/fdt.rs and vmm/src/cpu.rs declared the same
~14 cache info locals (size/line_size/sets for L1D/L1I/L2/L3, plus
shared flags for L2/L3), checked for /sys/devices/system/cpu/cpu0/cache,
and populated those locals via get_cache_size /
get_cache_coherency_line_size / get_cache_number_of_sets /
get_cache_shared. Two near-identical ~30-line blocks.
Add a CacheTopologyInfo struct in arch/src/aarch64/cache.rs whose
field names mirror the existing locals, plus a read_cache_topology()
helper that returns None when the sysfs hierarchy is missing and
only queries get_cache_shared for L2/L3 when their size is non-zero
(preserving current behavior).
Both call sites now obtain the info via read_cache_topology() and
destructure it back into locals of the same name, so all downstream
references are unchanged.
Assisted-by: Copilot-CLI:Claude-Opus-4.7
Signed-off-by: Anirudh Rayabharam <anrayabh@microsoft.com>
Replace 1024, 1024u32.pow(2), and 1024u32.pow(3) with 1u32 << 10,
1u32 << 20, and 1u32 << 30 in get_cache_size. The shift form makes
the binary (KiB/MiB/GiB) nature of the conversion immediately
obvious and is easier to read at a glance.
Signed-off-by: Anirudh Rayabharam <anrayabh@microsoft.com>
fdt.rs has helper functions to query host cache details (topology, size
etc.). Extract these helpers to a new file cache.rs so that they can be
used for PPTT construction as well.
No functional change.
Signed-off-by: Anirudh Rayabharam <anrayabh@microsoft.com>
The struct already implements ByteValued so this unsafe block can be
changed to call as_slice() from that trait.
Signed-off-by: Rob Bradford <rbradford@meta.com>
The struct already implements ByteValued so this unsafe block can be
changed to call as_slice() from that trait.
Signed-off-by: Rob Bradford <rbradford@meta.com>
Adds three recommendation bits to CPUID 0x40000004.EAX so Windows /
Hyper-V-aware guests use the corresponding paravirtualized hypercalls
instead of falling back to architectural primitives. The hypercalls
themselves are emulated unconditionally by KVM and surfaced via the
corresponding KVM_CAP_HYPERV_* info caps; no userspace cap negotiation
is needed because KVM advertises support to the guest at hypercall
issue time:
KVM_CAP_HYPERV_TLBFLUSH advertises HvFlush{VirtualAddressSpace,Ex,
List,ListEx} (api.rst 8.18, info-only cap).
KVM_CAP_HYPERV_SEND_IPI advertises HvCallSendSyntheticClusterIpi{,Ex}
(api.rst 8.20, also info-only).
Leaf 0x40000004.EAX (HV_CPUID_ENLIGHTMENT_INFO):
bit 1 LocalTlbFlushRecommended
bit 2 RemoteTlbFlushRecommended
Recommend HvFlushVirtualAddressSpace / List in place of
architectural INVPCID / INVLPG broadcasts. Remote shoot-down
via hypercall lets the host skip vCPUs that are not currently
scheduled, instead of waiting for an IPI ack.
bit 10 ClusterIpiRecommended
Recommend HvCallSendSyntheticClusterIpi over per-target APIC
ICR writes. A single hypercall can target up to 64 vCPUs (or
all of them via the Ex variant) versus one VM exit per APIC
access on the architectural path.
These bits depend on AccessVpIndex (0x40000003.EAX bit 6), which is
advertised by the partition-privileges change.
Sources:
Microsoft Hypervisor Top-Level Functional Specification 7.4.5
qemu/qemu docs/system/i386/hyperv.rst (hv-tlbflush, hv-ipi)
Linux Documentation/virt/kvm/api.rst 8.18, 8.20
Signed-off-by: CMGS <ilskdw@gmail.com>
Extends the Hyper-V partition feature CPUID leaf 0x40000003 with bits
that KVM emulates unconditionally and that Windows / Hyper-V-aware
guests consult to skip slow fallback paths. No KVM capability
negotiation is required for any of these -- they are hints to the
guest about what is already legal to use.
Leaf 0x40000003.EAX (HV_CPUID_FEATURES):
bit 0 AccessVpRuntimeReg -- HV_X64_MSR_VP_RUNTIME (0x40000010)
bit 4 AccessIntrCtrlRegs -- HV_X64_MSR_{EOI,ICR,TPR,APIC_ASSIST}
bit 11 AccessFrequencyMsrs -- HV_X64_MSR_{TSC,APIC}_FREQUENCY (skips
guest TSC/APIC calibration loops)
Leaf 0x40000003.EDX (HV_CPUID_FEATURES, TLFS rev 6.0c):
bit 4 FastHypercall -- HV_HYPERCALL_PARAMS_XMM_AVAILABLE
bit 8 ExtendedGvaRangesForFlushVirtualAddressList -- pairs with the
tlbflush-ext recommendation bit
AccessHypercallMsrs (bit 5) and AccessVpIndex (bit 6) are already
advertised by the partition-privileges change.
Sources:
Microsoft Hypervisor Top-Level Functional Specification 7.4.{2,5}
qemu/qemu docs/system/i386/hyperv.rst (hv-vapic, hv-frequencies,
hv-vpruntime)
Signed-off-by: CMGS <ilskdw@gmail.com>
size_of is part of std::prelude as of Rust 1.80 (with size_of_val,
align_of, align_of_val), and the workspace MSRV is 1.89, so qualifying
it (mem::size_of, std::mem::size_of, core::mem::size_of) is unnecessary.
Convert every qualified size_of call-site to the bare prelude form and
drop the now-redundant `use std::mem::size_of;` imports, keeping
`use std::mem;` where it still serves non-prelude items (transmute,
swap, replace, take, zeroed, MaybeUninit, offset_of). size_of is the
only one of the four currently used in the tree.
Pure refactor, no behavioural change. Follow-up to the
clippy::absolute_paths cleanup (#7670), as discussed in #8444.
Signed-off-by: Henry Hrvoje Tonkovac <htonkovac@gmail.com>
Assisted-by: Claude:Opus-4.8
Import the std modules used in the crate instead of spelling the full
paths at every use site, and drop the now-unnecessary crate-level
#![expect(clippy::absolute_paths)].
Signed-off-by: Henry Hrvoje Tonkovac <htonkovac@gmail.com>
Assisted-by: Claude:Opus-4.8
The RISC-V device tree's timebase-frequency was hardcoded to 10 MHz
(0x989680). Actual hardware uses different frequencies.
Read the timebase frequency from KVM_GET_ONE_REG via
KVM_REG_RISCV_TIMER (offset 0, kvm_riscv_timer.frequency),
thread it through the VMM to arch to FDT layers, and fall back to
the 10 MHz default when KVM returns no value.
Signed-off-by: Meng Zhuo <mengzhuo@iscas.ac.cn>
Removal of absolute paths is currently in progress. To avoid regressing
those changes add a clippy deny at the workspace level and at the crate
level override with #[expect(clippy::absolute_paths)]
See: #7670
Signed-off-by: Rob Bradford <rbradford@meta.com>
The Microsoft "Requirements for Implementing the Microsoft Hypervisor
Interface" document marks exactly two privileges in CPUID leaf
0x40000003 EAX as "Must be set": AccessHypercallMsrs (bit 5) and
AccessVpIndex (bit 6). Cloud Hypervisor advertised neither.
Without bit 5, Windows guests abort enlightened-mode initialization
before timer-API selection: HalpHvTimerApi is left NULL and every
QueryPerformanceCounter call falls back to reading
HV_X64_MSR_TIME_REF_COUNT (0x40000020), costing one VM exit per call.
The guest never writes HV_X64_MSR_REFERENCE_TSC (0x40000021) to enable
the reference TSC page, even though AccessPartitionReferenceTsc (bit 9)
is advertised.
With both bits set, Windows 10 22H2 and Windows 11 25H2 guests enable
the reference TSC page at boot. Measured QueryPerformanceCounter
throughput on a nested-KVM host went from ~71K calls/sec (14 us/call,
one MSR exit each) to ~1.3M calls/sec (free, no exits); on bare metal
from ~390K to ~1.9M calls/sec. Guest idle CPU and interrupt-service
time drop correspondingly.
Both MSR ranges are already handled in-kernel by KVM unconditionally,
so no backend change is needed. Bisection across the full delta to
QEMU's Hyper-V CPUID layout (vendor ID, max leaf, leaves 4-6 contents,
build number) shows bit 5 is the only load-bearing change; bit 6 is
included per the conformance document's mandate.
Signed-off-by: Tonic Li <tonic@simular.ai>
Signed-off-by: tonic <tonicbupt@gmail.com>
Remove stale #[allow]s whose lints no longer fire (a module-level
non_camel_case_types in mpspec, and a too_many_arguments on a riscv64
configure_system that no longer exceeds the argument threshold), and
convert the still-needed ones to #[expect].
Part of #8326.
Signed-off-by: Tushar Khatri <hello@tusharkhatri.in>
get_host_cpu_phys_bits() subtracts the SME c-bit reduction from
PhysAddrSize (CPUID 0x80000008 EAX bits 7:0). The result sets the
guest's CPUID and MMIO address space size.
The c-bit reduction is not needed here. QEMU's equivalent
(host_cpu_phys_bits() in target/i386/host-cpu.c) returns
PhysAddrSize without reduction.
Signed-off-by: Ruben Hakobyan <hruben@meta.com>
When generating guest CPUID, we set PhysAddrSize (EAX bits 7:0)
based on the host's physical address bits. On AMD hosts with SME,
get_host_cpu_phys_bits() subtracts the c-bit reduction from this
value, but the code here only writes the result to bits 7:0 and
leaves GuestPhysAddrSize (bits 23:16) at the unmodified host value.
This creates a gap: e.g. PhysAddrSize=43 but GuestPhysAddrSize=48.
Guest firmware that reads GuestPhysAddrSize will see a larger
address space than the VMM provides, and may place PCI BARs beyond
the MMIO bus range. However, Cloud-hypervisor sizes its MMIO bus to
phys_bits.
Fix by setting both PhysAddrSize (bits 7:0) and GuestPhysAddrSize
(bits 23:16) to phys_bits, using mask 0xff00_ff00 instead of
0xffff_ff00.
Signed-off-by: Ruben Hakobyan <hruben@meta.com>
Add unit tests that walk the SMBIOS binary layout in guest memory and
verify structure ordering, string-set encoding, and error paths.
Tests added:
- smbios_chassis_empty_string_set_has_double_null: verify that
a chassis with no strings emits the double-NUL terminator required
by SMBIOS DSP0134 §6.1.3.
- smbios_chassis_oem_strings_layout: verify the full chain
(BIOS → System → Chassis → OEM → End) when a chassis asset tag and
OEM strings are configured.
- smbios_strings_terminators_default: verify the default table chain
(BIOS → System → End) and check that string indices and string-set
contents match for both structures.
- smbios_strings_too_many: exercise alloc_index up to the u8 limit
(255 strings) and verify the 256th is rejected.
- smbios_uuid_invalid_rejected: ensure a malformed UUID string is
rejected with Error::ParseUuid.
- smbios_uuid_written_le: ensure the UUID is stored in little-endian
byte order as required by SMBIOS Spec 7.2.1.
- smbios_write_fails_with_too_small_memory: verify that setup_smbios
fails with Error::WriteData when guest memory is too small to hold
anything beyond the entry point.
All tests also succeed when run with miri:
cargo +nightly miri test -p arch smbios
On-behalf-of: SAP leander.kohler@sap.com
Signed-off-by: Leander Kohler <leander.kohler@cyberus-technology.de>
Extend SMBIOS System Information with manufacturer, product,
version, family, sku, serial, and uuid fields, add a chassis
asset tag, and pass a structured SMBIOS config from --platform
into arch setup. Keep OEM strings and legacy serial_number/uuid
options working for compatibility. The platform option naming
follows `dmidecode -s <field>`.
Fields:
- system_manufacturer
- system_product_name
- system_version
- system_family
- system_serial_number
- system_uuid
- chassis_asset_tag
On-behalf-of: SAP leander.kohler@sap.com
Signed-off-by: Leander Kohler <leander.kohler@cyberus-technology.de>
Add a small SMBIOS config that carries serial_number, uuid,
and OEM strings, and pass it from platform config into
x86_64 setup.
On-behalf-of: SAP leander.kohler@sap.com
Signed-off-by: Leander Kohler <leander.kohler@cyberus-technology.de>
Split the System Information write into helper functions and
reuse the string writer so the table layout and inputs are
unchanged.
On-behalf-of: SAP leander.kohler@sap.com
Signed-off-by: Leander Kohler <leander.kohler@cyberus-technology.de>
We make a slightly more general `check_cpuid_compatibility` function
that permits the caller to specify something else than "source VM" and
"destination VM" when logging an error.
This way we can reuse the existing CPUID compatibility checks to
ensure that the host VM is compatibile with the user selected CPU
profile.
In order to avoid a "refactor the world scenario" we keep the old
function with its signature and instead refactor it to call the new
more general internal function.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
We integrate the CPU profile into the various configs that
ultimately get set by the user.
This quickly ends up involving multiple files, luckily Rust
helps us find which ones via compilation errors.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Introduce a method on `CpuProfile` that is used to adjust the given
CPUID entries according to the chosen CPU profile.
This will be used in a later commit to apply the user chosen CPU
profile.
This commit also introduces a few unit tests using relatively simple,
somewhat contrived input values.
We will introduce snapshot tests with realistic adjustments
and CPUID entries in our planned follow up PR bringing in our
pregenerated CPU profiles.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Introduce a CpuProfile enum that will be deserialized from the user's
selected CPU profile.
Currently we only have a "host" variant, but in the future there will
be a build script automatically constructing this enum based on
pre-generated CPU profiles.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Introduce a struct for holding CPUID adjustments related to a
CPU profile.
Instances of this struct will typically be de-serialized from JSON files
describing a CPU profile.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
We introduce a type representing CPUID parameters that will be utilized
by the CPU profiles.
We place this new type in a module that will be further populated with
types related to adjusting CPUID entries based on the CPU profile
in a follow up commit.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Not all invariants can be effectively enforced by Rust's type system
and when this is the case we typically want tests that assert that the
promised invariants do indeed hold.
To get good confidence that our invariants do indeed hold we want to
check against many inputs, but having to write down many inputs is
tedious, and we may also be "biased" in our choices.
Property based testing helps here as it provides several randomly
generated inputs for us and we can focus on just writing the
test logic.
We thus add the popular user friendly `proptest` library as a
dev-dependency in order to write property based tests in follow up
commits. We emphasize that this will be particularly important in
a follow up PR where we have some relatively complex logic for
filtering MSRs.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Also derive Eq, Serialize and Deserialize for CpuidReg. This will make
it possible to reuse this existing type in the context of CPU profiles.
Signed-off-by: Oliver Anderson <oliver.anderson@cyberus-technology.de>
On-behalf-of: SAP oliver.anderson@sap.com
Import std::io and std::mem instead of spelling the full paths at every
use site.
Signed-off-by: Henry Hrvoje Tonkovac <htonkovac@gmail.com>
Assisted-by: Claude:Opus-4.7
Several riscv64 paths are compiled by the KVM build but missed
imports or cfg coverage needed by the current code.
Import the vm-memory Bytes trait for the RISC-V UEFI loader, keep
Instant available for migration timing code, and enable the UEFI flash
error path for riscv64.
Assisted-by: OpenAI-Codex:GPT-5
Signed-off-by: wangyf0611 <wangyufeng@iscas.ac.cn>
