On Wed, Apr 02, 2025 at 11:50:26 +0100, Daniel P. Berrangé wrote:
CC libvirt / Jiri, for confirmation about whether the CPUID restrictions listed below will have any possible impact on libvirt CPUID handling... ..
+Feature check +~~~~~~~~~~~~~ + +QEMU checks if the final (CPU) features, determined by given cpu model and +explicit feature adjustment of "+featureA/-featureB", can be supported or not. +It can produce feature not supported warning like + + "warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]" + +It can also produce warning like + + "warning: TDX forcibly sets the feature: CPUID.80000007H:EDX.invtsc [bit 8]" + +if the fixed-1 feature is requested to be disabled explicitly. This is newly +added to QEMU for TDX because TDX has fixed-1 features that are forcibly enabled +by TDX module and VMM cannot disable them.
This is where I'm wondering if libvirt has anything to be concerned about. Possibly when libvirt queries the actual CPUID after launching the guest it will just "do the right thing" ? Wondering if there's any need for libvirt to be aware of CPUID restrictions before that point though ?
Yes, it will do the right thing. Unless a user explicitly requests check='full'. Libvirt will use check='full' on its own only during migration and at that point the CPU definition is already modified according to what QEMU changed when the domain was started. So this will just work. For explicit check='full' to be usable we'd need a way to tell users which features are required/forbidden with TDX. But to be honest I don't think this is needed. Jirka