Radim Krčmář <rkrcmar@xxxxxxxxxx> writes: ... >> Why do you think it's a bug ? > > SDM defines a different behavior and hardware doesn't do that either. > There are only two reasons for a VMFUNC VM exit from EPTP switching: > > 1) ECX > 0 > 2) EPTP would cause VM entry to fail if in VMCS.EPT_POINTER > > KVM can fail for other reasons because of its bugs, but that should be > notified to the guest in another way. Rebooting the guest is kind of > acceptable in that case. > >> The eptp switching function really didn't >> succeed as far as our emulation goes when kvm_mmu_reload() fails. >> And as such, the generic vmexit failure event should be a vmfunc vmexit. > > I interpret it as two separate events -- at first, the vmfunc succeeds > and when it later tries to access memory through the new EPTP (valid, > but not pointing into backed memory), it results in a EPT_MISCONFIG VM > exit. > >> We cannot strictly follow the spec here, the spec doesn't even mention a way >> to emulate eptp switching. If setting up the switching succeeded and the >> new root pointer is invalid or whatever, I really don't care what happens >> next but this is not the case. We fail to get a new root pointer and without >> that, we can't even make a switch! > > We just make it behave exactly how the spec says that it behaves. We do > have a value (we read 'address') to put into VMCS.EPT_POINTER, which is > all we need for the emulation. > The function doesn't dereference that pointer, it just looks at its > value to decide whether it is valid or not. (btw. we should check that > properly, because we cannot depend on VM entry failure pass-through like > the normal case.) > > The dereference done in kvm_mmu_reload() should happen after EPTP > switching finishes, because the spec doesn't mention a VM exit for other > reason than invalid EPT_POINTER value. > >>> just keep the original bug -- we want to eventually fix it and it's no >>> worse till then. >> >> Anyway, can you please confirm again what is the behavior that you >> are expecting if kvm_mmu_reload fails ? This would be a rarely used >> branch and I am actually fine diverging from what I think is right if >> I can get the reviewers to agree on a common thing. > > kvm_mmu_reload() fails when mmu_check_root() is false, which means that > the pointed physical address is not backed. We've hit this corner-case > in the past -- Jim said that the chipset returns all 1s if a read is not > claimed. > > So in theory, KVM should not fail kvm_mmu_reload(), but behave as if the > pointer pointed to a memory of all 1s, which would likely result in > EPT_MISCONFIG when the guest does a memory access. As much as I would like to disagree with you, I have already spent way more time on this then I want. Please let's just leave it here, then ? The mmu unload will make sure there's an invalid root hpa and whatever happens next, happens. > It is a mishandled corner case, but turning it into VM exit would only > confuse an OS that receives the impossible VM exit and potentially > confuse reader of the KVM logic. > > I think that not using kvm_mmu_reload() directly in EPTP switching is > best. The bug is not really something we care about.
