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