[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <224d266e-aea3-3b4b-ec25-7bb120c4d98a@amazon.com>
Date: Fri, 23 Apr 2021 11:24:04 +0200
From: Alexander Graf <graf@...zon.com>
To: Siddharth Chandrasekaran <sidcha@...zon.de>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
"Vitaly Kuznetsov" <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
"Jim Mattson" <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"Borislav Petkov" <bp@...en8.de>, <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>
CC: Evgeny Iakovlev <eyakovl@...zon.de>, Liran Alon <liran@...zon.com>,
Ioannis Aslanidis <iaslan@...zon.de>, <kvm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: hyper-v: Add new exit reason HYPERV_OVERLAY
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@...zon.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
Powered by blists - more mailing lists