From: Sean Christopherson <seanjc@google.com>
To: Vishal Annapurve <vannapurve@google.com>
Cc: x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
pbonzini@redhat.com, shuah@kernel.org, bgardon@google.com,
oupton@google.com, peterx@redhat.com, vkuznets@redhat.com,
dmatlack@google.com, pgonda@google.com, andrew.jones@linux.dev
Subject: Re: [V3 PATCH 2/2] KVM: selftests: x86: Add native hypercall support
Date: Fri, 23 Dec 2022 00:37:16 +0000 [thread overview]
Message-ID: <Y6T4PJfF3nGU25Ee@google.com> (raw)
In-Reply-To: <20221222230458.3828342-3-vannapurve@google.com>
On Thu, Dec 22, 2022, Vishal Annapurve wrote:
> Add an API to execute hypercall as per the cpu type by checking the
> underlying CPU. KVM emulates vmcall/vmmcall instruction by modifying
> guest memory contents with hypercall instruction as per the cpu type.
>
> Confidential VMs need to execute hypercall instruction without it being
> emulated by KVM as KVM can not modify guest memory contents.
>
> Signed-off-by: Vishal Annapurve <vannapurve@google.com>
> ---
> .../selftests/kvm/include/x86_64/processor.h | 3 +++
> .../selftests/kvm/lib/x86_64/processor.c | 18 ++++++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h
> index 4d5dd9a467e1..3617f83bb2e5 100644
> --- a/tools/testing/selftests/kvm/include/x86_64/processor.h
> +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h
> @@ -1039,6 +1039,9 @@ uint64_t *vm_get_page_table_entry(struct kvm_vm *vm, uint64_t vaddr);
> uint64_t kvm_hypercall(uint64_t nr, uint64_t a0, uint64_t a1, uint64_t a2,
> uint64_t a3);
>
> +uint64_t kvm_native_hypercall(uint64_t nr, uint64_t a0, uint64_t a1, uint64_t a2,
> + uint64_t a3);
> +
> void __vm_xsave_require_permission(int bit, const char *name);
>
> #define vm_xsave_require_permission(perm) \
> diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> index 1e93bb3cb058..429e55f2609f 100644
> --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c
> +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c
> @@ -1202,6 +1202,24 @@ uint64_t kvm_hypercall(uint64_t nr, uint64_t a0, uint64_t a1, uint64_t a2,
> return r;
> }
>
> +uint64_t kvm_native_hypercall(uint64_t nr, uint64_t a0, uint64_t a1, uint64_t a2,
Just do this in kvm_hypercall(). David didn't say "don't do that", he said "don't
do that in a single patch". Except for fix_hypercall_test, selftests should always
use the native hypercall instruction and not rely on KVM's patching, e.g. patching
will go sideways if someone gets clever and makes guest code not-writable.
> + uint64_t a3)
Align parameters.
> +{
> + uint64_t r;
> +
> + if (is_amd_cpu()) {
Curly brace is unnecessary. Though I think I'd prefer to not duplicate the asm
blob (too many darn inputs). It's a little ugly, but I prefer it over duplicating
the entire blob. The approach could also likely be macrofied for other hypercall
usage (future problem).
asm volatile("test %[use_vmmcall], %[use_vmmcall]\n\t"
"jnz 1f\n\t"
"vmcall\n\t"
"jmp 2f\n\t"
"1: vmmcall\n\t"
"2:"
: "=a"(r)
: "a"(nr), "b"(a0), "c"(a1), "d"(a2), "S"(a3),
[use_vmmcall] "r" (is_amd_cpu()));
return r;
next prev parent reply other threads:[~2022-12-23 0:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 23:04 [V3 PATCH 0/2] Execute hypercalls from guests according to cpu Vishal Annapurve
2022-12-22 23:04 ` [V3 PATCH 1/2] KVM: selftests: x86: Cache the cpu vendor type Vishal Annapurve
2022-12-23 0:24 ` Sean Christopherson
2022-12-23 2:45 ` Vishal Annapurve
2022-12-22 23:04 ` [V3 PATCH 2/2] KVM: selftests: x86: Add native hypercall support Vishal Annapurve
2022-12-23 0:37 ` Sean Christopherson [this message]
2022-12-23 17:37 ` [V3 PATCH 0/2] Execute hypercalls from guests according to cpu Paolo Bonzini
2022-12-23 22:36 ` Vishal Annapurve
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y6T4PJfF3nGU25Ee@google.com \
--to=seanjc@google.com \
--cc=andrew.jones@linux.dev \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=pgonda@google.com \
--cc=shuah@kernel.org \
--cc=vannapurve@google.com \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.