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
Subject: Re: [V4 PATCH 4/4] KVM: selftests: x86: Invoke kvm hypercall as per host cpu
Date: Mon, 9 Jan 2023 18:20:59 +0000 [thread overview]
Message-ID: <Y7xbC+leVdO0TRVE@google.com> (raw)
In-Reply-To: <20221228192438.2835203-5-vannapurve@google.com>
KVM: selftests: Use host's native hypercall instruction in kvm_hypercall()
On Wed, Dec 28, 2022, Vishal Annapurve wrote:
> Invoke vmcall/vmmcall instructions from kvm_hypercall as per host CPU
() for functions, i.e. kvm_hypercall().
> type.
s/type/vendor, "type" is too generic.
> CVMs and current kvm_hyerpcall callers need to execute hypercall
CVM isn't a not ubiquitous acronym. I would avoid it entirely because "CVM"
doesn't strictly imply memory encryption, e.g. KVM could still patch the guest in
a pKVM-like implementation.
Use the host CPU's native hypercall instruction, i.e. VMCALL vs. VMMCALL,
in kvm_hypercall(), as relying on KVM to patch in the native hypercall on
a #UD for the "wrong" hypercall requires KVM_X86_QUIRK_FIX_HYPERCALL_INSN
to be enabled and flat out doesn't work if guest memory is encrypted with
a private key, e.g. for SEV VMs.
next prev parent reply other threads:[~2023-01-09 18:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-28 19:24 [V4 PATCH 0/4] Execute hypercalls according to host cpu Vishal Annapurve
2022-12-28 19:24 ` [V4 PATCH 1/4] KVM: selftests: x86: use this_cpu_* helpers Vishal Annapurve
2023-01-09 18:07 ` Sean Christopherson
2023-01-10 23:56 ` Vishal Annapurve
2022-12-28 19:24 ` [V4 PATCH 2/4] KVM: selftests: x86: Add variables to store cpu type Vishal Annapurve
2023-01-09 18:13 ` Sean Christopherson
2023-01-11 0:13 ` Vishal Annapurve
2022-12-28 19:24 ` [V4 PATCH 3/4] KVM: sefltests: x86: Replace is_*cpu with is_host_*cpu Vishal Annapurve
2022-12-28 19:24 ` [V4 PATCH 4/4] KVM: selftests: x86: Invoke kvm hypercall as per host cpu Vishal Annapurve
2023-01-09 18:20 ` Sean Christopherson [this message]
2023-01-11 0:18 ` Vishal Annapurve
2023-01-04 19:32 ` [V4 PATCH 0/4] Execute hypercalls according to " David Matlack
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=Y7xbC+leVdO0TRVE@google.com \
--to=seanjc@google.com \
--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=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.