> On Jul 4, 2020, at 11:38 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 04/07/20 02:00, Nadav Amit wrote: >> Hello Paolo, >> >> I encountered an issue while running some svm tests. Apparently, the tests >> “npt_rw_pfwalk” and “npt_rsv_pfwalk” expect the present bit to be clear. >> >> KVM indeed clears this bit in nested_svm_inject_npf_exit(): >> >> /* >> * The present bit is always zero for page structure faults on real >> * hardware. >> */ >> if (svm->vmcb->control.exit_info_1 & (2ULL << 32)) >> svm->vmcb->control.exit_info_1 &= ~1; >> >> >> I could not find documentation of this behavior. Unfortunately, I do not >> have a bare-metal AMD machine to test the behavior (and some enabling of >> kvm-unit-tests/svm is required, e.g. this test does not run with more than >> 4GB of memory). >> >> Are you sure that this is the way AMD machines behave? > > No, I'm not. The code was added when NPF was changed to synthesize > EXITINFO1, instead of simply propagating L0's EXITINFO1 into L1 (see > commit 5e3525195196, "KVM: nSVM: propagate the NPF EXITINFO to the > guest", 2014-09-03). With six more years of understanding of KVM, the > lack of a present bit might well have been a consequence of how the MMU > works. Thanks. I ran ‘git blame’ before asking you, and that is the reason I assumed you would know best... ;-) > One of these days I'd like to run the SVM tests under QEMU without KVM. > It would probably find bugs in both. Well, I think we can agree that bare-metal is a better reference than another emulator for the matter. Even without running the tests on bare-metal, it is easy to dump EXITINFO1 on the nested page-fault. I will try to find a bare-metal machine. Anyhow, I would appreciate if anyone from AMD would tell whether any result should be considered architectural.
