Re: [Bug 219085] kvm_spurious_fault in L1 when running a nested kvm instance on AMD Opteron_G5_qemu L0

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 23, 2024, bugzilla-daemon@kernel.org wrote:
> I also saw a claim from Peter Maydell, qemu developer, who had said this about
> qemu command line parameter `-cpu _processor_type_`:
> > using a specific cpu type will only work with KVM if the host CPU really is
> > that exact CPU type, otherwise, use "-cpu host" or "-cpu max".

This generally isn't true.  KVM is very capable of running older vCPU models on
newer hardware.  What won't work (at least, not well) is cross-vendor virtualization,
i.e. advertising AMD on Intel and vice versa, but that's not what you're doing.

> > This is a restriction in the kernel's KVM handling, and not something that
> > can be worked around in the QEMU side.
> Per https://gitlab.com/qemu-project/qemu/-/issues/239
> 
> I was somewhat confused by this claim because 
> > --- Comment #1 from ununpta@mailto.plus ---
> > Command I used on L0 AMD Ryzen:
> > qemu-system-x86_64.exe -m 4096 -machine q35 -accel whpx -smp 1 -cpu
> > Opteron_G5
> 
> Let me ask you a few questions.
> Q1: Can one use an older cpu (but still supporting SVM), not the actual bare
> one in qemu command line for nested virtualization or KVM will crash due to
> restriction in the kernel's KVM handling?

Yes.  There might be caveats, but AFAIK, QEMU's predefined vCPU models should
always work.  If it doesn't work, and you have decent evidence that it's a KVM
problem, definitely feel free to file a KVM bug.

> Q2: Is there a command in bare Kernel/KVM console to figure out if EFER.SVME
> register/bit is writeable? If not,

grep -q svm /proc/cpuinfo

SVM can be disabled by firmware via MSR_VM_CR (0xc0010114) even if SVM is reported
in raw CPUID, but the kernel accounts for that and clears the "svm" flag from the
CPU data that's reported in /proc/cpuinfo.

> Q3: Can you recommend any package to figure out it?

Sorry, I don't follow this question.