mbox series

[RFC,V2,0/8] selftests: KVM: selftests for fd-based approach of supporting private memory

Message ID 20220511000811.384766-1-vannapurve@google.com (mailing list archive)
Headers show
Series selftests: KVM: selftests for fd-based approach of supporting private memory | expand

Message

Vishal Annapurve May 11, 2022, 12:08 a.m. UTC
This v2 series implements selftests targeting the feature floated by Chao
via:
https://lore.kernel.org/linux-mm/20220310140911.50924-1-chao.p.peng@linux.intel.com/

Below changes aim to test the fd based approach for guest private memory
in context of normal (non-confidential) VMs executing on non-confidential
platforms.

priv_memfd_test.c file adds a suite of selftests to access private memory
from the guest via private/shared accesses and checking if the contents
can be leaked to/accessed by vmm via shared memory view.

Updates in V2:
1) Tests are added to exercise implicit/explicit memory conversion paths.
2) Test is added to exercise UPM feature without double memory allocation.

This series has dependency on following patches:
1) V5 series patches from Chao mentioned above.
2) https://github.com/vishals4gh/linux/commit/b9adedf777ad84af39042e9c19899600a4add68a
  - Fixes host kernel crash with current implementation
3) https://github.com/vishals4gh/linux/commit/0577e351ee36d52c1f6cdcb1b8de7aa6b5f760fe
  - Confidential platforms along with the confidentiality aware software stack
    support a notion of private/shared accesses from the confidential VMs.
    Generally, a bit in the GPA conveys the shared/private-ness of the access.

    Non-confidential platforms don't have a notion of private or shared accesses
    from the guest VMs. To support this notion, KVM_HC_MAP_GPA_RANGE is modified
    to allow marking an access from a VM within a GPA range as always shared or
    private. There is an ongoing discussion about adding support for
    software-only confidential VMs, which should replace this patch.
4) https://github.com/vishals4gh/linux/commit/8d46aea9a7d72e4b1b998066ce0dde085fb963a7
  - Temporary placeholder to be able to test memory conversion paths
    till the memory conversion exit error code is finalized.
5) https://github.com/vishals4gh/linux/commit/4c36706477c62d9416d635fa6ac4ef6484014dfc
  - Fixes GFN calculation during memory conversion path.

Github link for the patches posted as part of this series:
https://github.com/vishals4gh/linux/commits/priv_memfd_selftests_rfc_v2

Austin Diviness (1):
  selftests: kvm: Add hugepage support to priv_memfd_test suite.

Vishal Annapurve (7):
  selftests: kvm: Fix inline assembly for hypercall
  selftests: kvm: Add a basic selftest to test private memory
  selftests: kvm: priv_memfd_test: Add support for memory conversion
  selftests: kvm: priv_memfd_test: Add shared access test
  selftests: kvm: Add implicit memory conversion tests
  selftests: kvm: Add KVM_HC_MAP_GPA_RANGE hypercall test
  selftests: kvm: priv_memfd: Add test avoiding double allocation

 tools/testing/selftests/kvm/Makefile          |    1 +
 .../selftests/kvm/lib/x86_64/processor.c      |    2 +-
 tools/testing/selftests/kvm/priv_memfd_test.c | 1359 +++++++++++++++++
 3 files changed, 1361 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/kvm/priv_memfd_test.c

Comments

Shuah Khan May 12, 2022, 6:04 p.m. UTC | #1
On 5/10/22 6:08 PM, Vishal Annapurve wrote:
> This v2 series implements selftests targeting the feature floated by Chao
> via:
> https://lore.kernel.org/linux-mm/20220310140911.50924-1-chao.p.peng@linux.intel.com/
> 
> Below changes aim to test the fd based approach for guest private memory
> in context of normal (non-confidential) VMs executing on non-confidential
> platforms.
> 
> priv_memfd_test.c file adds a suite of selftests to access private memory
> from the guest via private/shared accesses and checking if the contents
> can be leaked to/accessed by vmm via shared memory view.
> 
> Updates in V2:
> 1) Tests are added to exercise implicit/explicit memory conversion paths.
> 2) Test is added to exercise UPM feature without double memory allocation.
> 

+ shuah <shuah@kernel.org>

Adding  my correct kernel.org address. Please make sure to run
get_maintainers.pl to get the right addresses for miantianers.

thanks,
-- Shuah
Vishal Annapurve May 12, 2022, 6:18 p.m. UTC | #2
On Thu, May 12, 2022 at 11:04 AM Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> + shuah <shuah@kernel.org>
>
> Adding  my correct kernel.org address. Please make sure to run
> get_maintainers.pl to get the right addresses for miantianers.
>

Thanks Shuah for the feedback. Apologies for the typo in the email address.

I will address the comments in the next version.

Regards,
Vishal
Sean Christopherson July 20, 2022, 10:19 p.m. UTC | #3
On Wed, May 11, 2022, Vishal Annapurve wrote:
>  tools/testing/selftests/kvm/priv_memfd_test.c | 1359 +++++++++++++++++

Please don't create a megatest.  We have megatests for nVMX and nSVM in KVM-Unit-Test
and IMO they are a mistake.  E.g. to run a single test instead of the entire suite,
the KUT tests provide a funky wildcard/filter syntax.  But the names of the tests
aren't discoverable, so inevitably I have to look at the source code to figure out
the exact name of the test I want to run.  And don't get me started on sub-tests
within sub-tests...

AFAICT, what you've proposed here doesn't provide any such filter mechanism.  And
I would rather we NOT start adding those to selftests, because we'd effectively be
reinventing the wheel _and_ dealing with strings in C is a pain.  Writing a script
to find and run all tests is trivial, e.g. grep the .gitignore to find tests for
the target arch.  Or when the system under test is different than the build system,
copy the binaries to a dedicated directory and run every binary in that directory.

Discovering and running a single test is similarly trivial.  For KUT, it's less
trivial because running a test involves invoking a VMM command line, and some of
the tests need specific command line parameters.  But for selftests, except for the
NX huge page test, they're all standalone and don't need additional setup.

And unlike KUT's nVMX and nSVM tests, which involve running hundreds of little
sub-tests with only minor differences in setup, these tests are largely independent,
i.e. you're not really getting much code reuse.

And if you split the tests up, then all of the inter-test namespacing goes away,
e.g. there is zero chance I will ever remember what "PSPAHCT" stands for.

+#define PSPAHCT_GUEST_STARTED                          0ULL
+#define PSPAHCT_GUEST_PRIVATE_MEM_UPDATED              1ULL
+#define PSPAHCT_GUEST_SHARED_MEM_UPDATED               2ULL
+#define PSPAHCT_GUEST_PRIVATE_MEM_UPDATED2             3ULL

If you find yourself doing a lot of copy+paste, then we should enhance the APIs
provided by the core infrastructure.