* Question regarding nested_svm_inject_npf_exit()
@ 2020-07-04 0:00 Nadav Amit
2020-07-05 6:38 ` Paolo Bonzini
0 siblings, 1 reply; 6+ messages in thread
From: Nadav Amit @ 2020-07-04 0:00 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
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?
Thanks,
Nadav
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding nested_svm_inject_npf_exit()
2020-07-04 0:00 Question regarding nested_svm_inject_npf_exit() Nadav Amit
@ 2020-07-05 6:38 ` Paolo Bonzini
2020-07-06 2:12 ` Nadav Amit
0 siblings, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2020-07-05 6:38 UTC (permalink / raw)
To: Nadav Amit; +Cc: kvm
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.
One of these days I'd like to run the SVM tests under QEMU without KVM.
It would probably find bugs in both.
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding nested_svm_inject_npf_exit()
2020-07-05 6:38 ` Paolo Bonzini
@ 2020-07-06 2:12 ` Nadav Amit
2020-07-06 23:26 ` Jim Mattson
0 siblings, 1 reply; 6+ messages in thread
From: Nadav Amit @ 2020-07-06 2:12 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm
> On Jul 4, 2020, at 11:38 PM, Paolo Bonzini <pbonzini@redhat.com> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding nested_svm_inject_npf_exit()
2020-07-06 2:12 ` Nadav Amit
@ 2020-07-06 23:26 ` Jim Mattson
2020-07-07 6:02 ` Paolo Bonzini
0 siblings, 1 reply; 6+ messages in thread
From: Jim Mattson @ 2020-07-06 23:26 UTC (permalink / raw)
To: Nadav Amit; +Cc: Paolo Bonzini, kvm
On Sun, Jul 5, 2020 at 7:12 PM Nadav Amit <nadav.amit@gmail.com> wrote:
>
> > On Jul 4, 2020, at 11:38 PM, Paolo Bonzini <pbonzini@redhat.com> 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.
I'd be happy to test on bare metal, but I'm still waiting for
instructions that a script kiddie (with read-only console access) can
follow.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding nested_svm_inject_npf_exit()
2020-07-06 23:26 ` Jim Mattson
@ 2020-07-07 6:02 ` Paolo Bonzini
2020-07-07 6:29 ` Nadav Amit
0 siblings, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2020-07-07 6:02 UTC (permalink / raw)
To: Jim Mattson, Nadav Amit; +Cc: kvm
On 07/07/20 01:26, Jim Mattson wrote:
>> 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.
>
> I'd be happy to test on bare metal, but I'm still waiting for
> instructions that a script kiddie (with read-only console access) can
> follow.
I'll try to test myself and prepare some instructions.
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding nested_svm_inject_npf_exit()
2020-07-07 6:02 ` Paolo Bonzini
@ 2020-07-07 6:29 ` Nadav Amit
0 siblings, 0 replies; 6+ messages in thread
From: Nadav Amit @ 2020-07-07 6:29 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Jim Mattson, kvm
> On Jul 6, 2020, at 11:02 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 07/07/20 01:26, Jim Mattson wrote:
>>> 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.
>>
>> I'd be happy to test on bare metal, but I'm still waiting for
>> instructions that a script kiddie (with read-only console access) can
>> follow.
>
> I'll try to test myself and prepare some instructions.
Sorry for the late response (divorce, it turns out, is very time consuming).
I will try to send you scripts later on, but I did not automate things
through the iDRAC.
I managed to get an AMD machine, but unfortunately non of the tests run
on that machine. I am still trying to figure it out. I will update you
once I make progress.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-07-07 6:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-04 0:00 Question regarding nested_svm_inject_npf_exit() Nadav Amit
2020-07-05 6:38 ` Paolo Bonzini
2020-07-06 2:12 ` Nadav Amit
2020-07-06 23:26 ` Jim Mattson
2020-07-07 6:02 ` Paolo Bonzini
2020-07-07 6:29 ` Nadav Amit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).