https://bugzilla.kernel.org/show_bug.cgi?id=219085 --- Comment #5 from ununpta@xxxxxxxxxxx --- Sean, after looking into AMD documentation on https://unix.stackexchange.com/questions/74376 I think it's clear why KVM in L1 crashes. AMD says: > Secure Virtual Machine Enable (SVME) Bit. Bit 12, read/write. Enables the SVM > extensions. When this bit is zero, the SVM instructions cause #UD exceptions. > EFER.SVME defaults to a reset value of zero. > The effect of turning off EFER.SVME while a guest is running is undefined; > therefore, the VMM should always prevent guests from writing EFER. > SVM extensions can be disabled by setting VM_CR.SVME_DISABLE. Command to read from EFER.SVME is `sudo rdmsr 0xC0000080 #EFER`. Both in non-working and working machines this command returns d01. d01 is 1101 0000 0001 in bin. Crashing command from Comment #1 did `WRMSR to 0xc0000080 (tried to write 0x0000000000001d01)`. 1d01 is 0001 1101 0000 0001 in bin. The leftmost 0001 is Bit 12. So crashing command in L1 tries to write Bit 12 to exclude #UD. Nested VM is impossible without Bit 12. Writing this bit needs 0ring priveleges, guests cannot do this but the VM manager can. VM manager hooks into the write operation, checks whether VM_CR.SVME_DISABLE == 0 and if true, sets the Bit 12 by itself with L0 priveleges, then returns success to the guest. This is what happens on Windows if KVM L1 runs on the top of native Windows Hyper-V manager L0. Qemu on windows does not hook into write command and guest tries to write the Bit with user privileges, which of course fails. Questions are: * How Does Processor determine who tries to write - L0 or L1? * Does KVM determine in its code source whether KVM itself runs on the top of Hyper-V or on the top of another KVM? * Should Qemu hook into WRMSR to 0xc0000080 (tried to write 0x0000000000001d01) coming from KVM if Qemu is accelerated by Hyper-V on L0 and KVM is L1? > Sorry, I don't follow this question. I figured out that the commands I had tried to describe turned out `sudo rdmsr 0xC0000080 #EFER` and `sudo rdmsr 0xC0010114 #VM_CR`. The package is called msr-tools :) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
