public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox