The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Alexander Graf <graf@amazon.com>
To: Siddharth Chandrasekaran <sidcha@amazon.de>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	"Jim Mattson" <jmattson@google.com>,
	Joerg Roedel <joro@8bytes.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>,
	<x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Evgeny Iakovlev <eyakovl@amazon.de>,
	Liran Alon <liran@amazon.com>,
	Ioannis Aslanidis <iaslan@amazon.de>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: hyper-v: Add new exit reason HYPERV_OVERLAY
Date: Fri, 23 Apr 2021 11:24:04 +0200	[thread overview]
Message-ID: <224d266e-aea3-3b4b-ec25-7bb120c4d98a@amazon.com> (raw)
In-Reply-To: <20210423090333.21910-1-sidcha@amazon.de>



On 23.04.21 11:03, Siddharth Chandrasekaran wrote:
> Hypercall code page is specified in the Hyper-V TLFS to be an overlay
> page, ie., guest chooses a GPA and the host _places_ a page at that
> location, making it visible to the guest and the existing page becomes
> inaccessible. Similarly when disabled, the host should _remove_ the
> overlay and the old page should become visible to the guest.
> 
> Currently KVM directly patches the hypercall code into the guest chosen
> GPA. Since the guest seldom moves the hypercall code page around, it
> doesn't see any problems even though we are corrupting the exiting data
> in that GPA.
> 
> VSM API introduces more complex overlay workflows during VTL switches
> where the guest starts to expect that the existing page is intact. This
> means we need a more generic approach to handling overlay pages: add a
> new exit reason KVM_EXIT_HYPERV_OVERLAY that exits to userspace with the
> expectation that a page gets overlaid there.

I can see how that may get interesting for other overlay pages later, 
but this one in particular is just an MSR write, no? Is there any reason 
we can't just use the user space MSR handling logic instead?

What's missing then is a way to pull the hcall page contents from KVM. 
But even there I'm not convinced that KVM should be the reference point 
for its contents. Isn't user space in an as good position to assemble it?

> 
> In the interest of maintaing userspace exposed behaviour, add a new KVM
> capability to allow the VMMs to enable this if they can handle the
> hypercall page in userspace.
> 
> Signed-off-by: Siddharth Chandrasekaran <sidcha@amazon.de>
> 
> CR: https://code.amazon.com/reviews/CR-49011379

Please remove this line from upstream submissions :).

> ---
>   arch/x86/include/asm/kvm_host.h |  4 ++++
>   arch/x86/kvm/hyperv.c           | 25 ++++++++++++++++++++++---
>   arch/x86/kvm/x86.c              |  5 +++++
>   include/uapi/linux/kvm.h        | 10 ++++++++++

You're modifying / adding a user space API. Please make sure to update 
the documentation in Documentation/virt/kvm/api.rst when you do that.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



  reply	other threads:[~2021-04-23  9:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23  9:03 [PATCH] KVM: hyper-v: Add new exit reason HYPERV_OVERLAY Siddharth Chandrasekaran
2021-04-23  9:24 ` Alexander Graf [this message]
2021-04-23  9:42   ` Siddharth Chandrasekaran
2021-04-23  9:50   ` Paolo Bonzini
2021-04-23  9:58     ` Alexander Graf
2021-04-23 10:15       ` Paolo Bonzini
2021-04-23 10:18         ` Alexander Graf
2021-04-26 21:41           ` Siddharth Chandrasekaran
2021-04-23  9:36 ` Vitaly Kuznetsov
2021-04-23 10:05   ` Siddharth Chandrasekaran

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=224d266e-aea3-3b4b-ec25-7bb120c4d98a@amazon.com \
    --to=graf@amazon.com \
    --cc=bp@alien8.de \
    --cc=eyakovl@amazon.de \
    --cc=hpa@zytor.com \
    --cc=iaslan@amazon.de \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liran@amazon.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=sidcha@amazon.de \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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