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
