| Message ID | 20211229062201.26269-1-manali.shukla@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add L2 exception handling KVM unit tests for nSVM | expand |
On 12/29/2021 11:51 AM, Manali Shukla wrote: > This series adds 3 KVM Unit tests for nested SVM > 1) Check #NM is handled in L2 when L2 #NM handler is registered > "fnop" instruction is called in L2 to generate the exception > > 2) Check #BP is handled in L2 when L2 #BP handler is registered > "int3" instruction is called in L2 to generate the exception > > 3) Check #OF is handled in L2 when L2 #OF handler is registered > "into" instruction with instrumented code is used in L2 to > generate the exception > > Manali Shukla (3): > x86: nSVM: Check #NM exception handling in L2 > x86: nSVM: Check #BP exception handling in L2 > x86: nSVM: Check #OF exception handling in L2 > > x86/svm_tests.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 114 insertions(+) > A gentle reminder for review Thank you, Manali
+Aaron, and +Paolo who may or may not subsribe to kvm@ :-) On Wed, Dec 29, 2021, Manali Shukla wrote: > This series adds 3 KVM Unit tests for nested SVM > 1) Check #NM is handled in L2 when L2 #NM handler is registered > "fnop" instruction is called in L2 to generate the exception > > 2) Check #BP is handled in L2 when L2 #BP handler is registered > "int3" instruction is called in L2 to generate the exception > > 3) Check #OF is handled in L2 when L2 #OF handler is registered > "into" instruction with instrumented code is used in L2 to > generate the exception This is all basically identical in terms of desired functionality to existing or in-flight nVMX tests, e.g. vmx_nm_test() and Aaron's vmx_exception_test() work[*]. And much of the feedback I provided to Aaron's earlier revisions applies to this series as well, e.g. create a framework to test intercpetion of arbitrary exceptions instead of writing the same boilerplate for each and every test. It doesn't seem like it'd be _that_ difficult to turn vmx_exception_test into a generic-ish l2_exception_test. To avoid too much scope creep, what if we first get Aaron's code merged, and than attempt to extract the core functionality into a shared library to reuse it for nSVM? If it turns out to be more trouble then its worth, we can always fall back to something like this series. [*] https://lore.kernel.org/all/20211214011823.3277011-1-aaronlewis@google.com
On 12/29/21 07:21, Manali Shukla wrote: > This series adds 3 KVM Unit tests for nested SVM > 1) Check #NM is handled in L2 when L2 #NM handler is registered > "fnop" instruction is called in L2 to generate the exception > > 2) Check #BP is handled in L2 when L2 #BP handler is registered > "int3" instruction is called in L2 to generate the exception > > 3) Check #OF is handled in L2 when L2 #OF handler is registered > "into" instruction with instrumented code is used in L2 to > generate the exception > > Manali Shukla (3): > x86: nSVM: Check #NM exception handling in L2 > x86: nSVM: Check #BP exception handling in L2 > x86: nSVM: Check #OF exception handling in L2 > > x86/svm_tests.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 114 insertions(+) > Queued, thanks. Paolo
On 1/13/2022 2:59 AM, Sean Christopherson wrote: > +Aaron, and +Paolo who may or may not subsribe to kvm@ :-) > > On Wed, Dec 29, 2021, Manali Shukla wrote: >> This series adds 3 KVM Unit tests for nested SVM >> 1) Check #NM is handled in L2 when L2 #NM handler is registered >> "fnop" instruction is called in L2 to generate the exception >> >> 2) Check #BP is handled in L2 when L2 #BP handler is registered >> "int3" instruction is called in L2 to generate the exception >> >> 3) Check #OF is handled in L2 when L2 #OF handler is registered >> "into" instruction with instrumented code is used in L2 to >> generate the exception > > This is all basically identical in terms of desired functionality to existing or > in-flight nVMX tests, e.g. vmx_nm_test() and Aaron's vmx_exception_test() work[*]. > And much of the feedback I provided to Aaron's earlier revisions applies to this > series as well, e.g. create a framework to test intercpetion of arbitrary exceptions > instead of writing the same boilerplate for each and every test. > > It doesn't seem like it'd be _that_ difficult to turn vmx_exception_test into a > generic-ish l2_exception_test. To avoid too much scope creep, what if we first get > Aaron's code merged, and than attempt to extract the core functionality into a > shared library to reuse it for nSVM? If it turns out to be more trouble then its > worth, we can always fall back to something like this series. > > [*] https://lore.kernel.org/all/20211214011823.3277011-1-aaronlewis@google.com This patch has already been queued by Paolo. I will wait till Aaron's code is merged and than do appropriate changes. I hope this is fine. Thank you Manali
On 1/18/22 12:11, Shukla, Manali wrote: >> >> It doesn't seem like it'd be_that_ difficult to turn vmx_exception_test into a >> generic-ish l2_exception_test. To avoid too much scope creep, what if we first get >> Aaron's code merged, and than attempt to extract the core functionality into a >> shared library to reuse it for nSVM? If it turns out to be more trouble then its >> worth, we can always fall back to something like this series. >> >> [*]https://lore.kernel.org/all/20211214011823.3277011-1-aaronlewis@google.com > This patch has already been queued by Paolo. > I will wait till Aaron's code is merged and than do appropriate changes. > I hope this is fine. Yes, it is. I am holding on Aaron's series because of the remarks from Sean[1], on the other hand it's really difficult to share code between VMX and SVM tests. So while I agree that a lot of code changes can be done the same way to VMX and SVM tests, it's not really feasible to keep them in sync. Paolo [1] https://lore.kernel.org/all/Yd8+n+%2F2GCZtIhaB@google.com/#t