Thread (45 messages) 45 messages, 5 authors, 2020-10-27

Re: [PATCH RFC v1 08/18] x86/hyperv: handling hypercall page setup for root

From: Wei Liu <wei.liu@kernel.org>
Date: 2020-09-15 11:35:43
Also in: lkml

On Tue, Sep 15, 2020 at 01:23:50PM +0200, Vitaly Kuznetsov wrote:
Wei Liu [off-list ref] writes:
quoted
On Tue, Sep 15, 2020 at 01:02:08PM +0200, Vitaly Kuznetsov wrote:
quoted
Wei Liu [off-list ref] writes:
quoted
On Tue, Sep 15, 2020 at 12:32:29PM +0200, Vitaly Kuznetsov wrote:
quoted
Wei Liu [off-list ref] writes:
quoted
When Linux is running as the root partition, the hypercall page will
have already been setup by Hyper-V. Copy the content over to the
allocated page.
And we can't setup a new hypercall page by writing something different
to HV_X64_MSR_HYPERCALL, right?
My understanding is that we can't, but Sunil can maybe correct me.
quoted
quoted
The suspend, resume and cleanup paths remain untouched because they are
not supported in this setup yet.

Signed-off-by: Lillian Grassin-Drake <redacted>
Signed-off-by: Sunil Muthuswamy <redacted>
Signed-off-by: Nuno Das Neves <redacted>
Co-Developed-by: Lillian Grassin-Drake <redacted>
Co-Developed-by: Sunil Muthuswamy <redacted>
Co-Developed-by: Nuno Das Neves <redacted>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
---
 arch/x86/hyperv/hv_init.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 0eec1ed32023..26233aebc86c 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -25,6 +25,7 @@
 #include <linux/cpuhotplug.h>
 #include <linux/syscore_ops.h>
 #include <clocksource/hyperv_timer.h>
+#include <linux/highmem.h>
 
 /* Is Linux running as the root partition? */
 bool hv_root_partition;
@@ -448,8 +449,29 @@ void __init hyperv_init(void)
 
 	rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 	hypercall_msr.enable = 1;
-	hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
-	wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+
+	if (hv_root_partition) {
+		struct page *pg;
+		void *src, *dst;
+
+		/*
+		 * Order is important here. We must enable the hypercall page
+		 * so it is populated with code, then copy the code to an
+		 * executable page.
+		 */
+		wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+
+		pg = vmalloc_to_page(hv_hypercall_pg);
+		dst = kmap(pg);
+		src = memremap(hypercall_msr.guest_physical_address << PAGE_SHIFT, PAGE_SIZE,
+				MEMREMAP_WB);
memremap() can fail...
And we don't care here, if it fails, we would rather it panic or oops.

I was relying on the fact that copying from / to a NULL pointer will
cause the kernel to crash. But of course it wouldn't hurt to explicitly
panic here.
quoted
quoted
+		memcpy(dst, src, PAGE_SIZE);
+		memunmap(src);
+		kunmap(pg);
+	} else {
+		hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
+		wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+	}
Why can't we do wrmsrl() for both cases here?
Because the hypercall page has already been set up when Linux is the
root.
But you already do wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64)
in 'if (hv_root_partition)' case above, that's why I asked.
You mean extracting wrmsrl to this point?  The ordering matters. See the
comment in the root branch -- we have to enable the page before copying
the content.

What can be done is:

   if (!root) {
       /* some stuff */
   }

   wrmsrl(...)

   if (root) {
       /* some stuff */
   }

This is not looking any better than the existing code.
Oh, I missed the comment indeed. So Hypervisor already picked a page for
us, however, it didn't enable it and it's not populated?
Seems to be the case.
How can we be
sure that we didn't use it for something else already?
It is a page deposited to the root partition and it is not going to be
used elsewhere, nor it is visible from the root. This is my
understanding. I will let Sunil correct me if I'm wrong.
Maybe we can
still give a different known-to-be-empty page?
That's the thing I said I didn't bother trying earlier. Something to
check when I have some spare cycles.

Wei.
-- 
Vitaly
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help