On Tue, Jul 23, 2024, bugzilla-daemon@xxxxxxxxxx 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@xxxxxxxxxxx --- > > 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.
