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.
The suspend, resume and cleanup paths remain untouched because they are
not supported in this setup yet.
Signed-off-by: Lillian Grassin-Drake <[email protected]>
Signed-off-by: Sunil Muthuswamy <[email protected]>
Signed-off-by: Nuno Das Neves <[email protected]>
Co-Developed-by: Lillian Grassin-Drake <[email protected]>
Co-Developed-by: Sunil Muthuswamy <[email protected]>
Co-Developed-by: Nuno Das Neves <[email protected]>
Signed-off-by: Wei Liu <[email protected]>
---
arch/x86/hyperv/hv_init.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 73b0fb851f76..9fcaf741be99 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;
@@ -438,8 +439,35 @@ 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;
+
+ /*
+ * For the root partition, the hypervisor will set up its
+ * hypercall page. The hypervisor guarantees it will not show
+ * up in the root's address space. The root can't change the
+ * location of the hypercall page.
+ *
+ * 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);
+ BUG_ON(!(src && dst));
+ 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);
+ }
/*
* Ignore any errors in setting up stimer clockevents
--
2.20.1
Wei Liu <[email protected]> writes:
> 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.
>
> The suspend, resume and cleanup paths remain untouched because they are
> not supported in this setup yet.
What about adding BUG_ONs there then?
>
> Signed-off-by: Lillian Grassin-Drake <[email protected]>
> Signed-off-by: Sunil Muthuswamy <[email protected]>
> Signed-off-by: Nuno Das Neves <[email protected]>
> Co-Developed-by: Lillian Grassin-Drake <[email protected]>
> Co-Developed-by: Sunil Muthuswamy <[email protected]>
> Co-Developed-by: Nuno Das Neves <[email protected]>
> Signed-off-by: Wei Liu <[email protected]>
> ---
> arch/x86/hyperv/hv_init.c | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 73b0fb851f76..9fcaf741be99 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;
> @@ -438,8 +439,35 @@ 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;
> +
> + /*
> + * For the root partition, the hypervisor will set up its
> + * hypercall page. The hypervisor guarantees it will not show
> + * up in the root's address space. The root can't change the
> + * location of the hypercall page.
> + *
> + * 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);
> + BUG_ON(!(src && dst));
> + memcpy(dst, src, PAGE_SIZE);
Super-nit: while on x86 PAGE_SIZE always matches HV_HYP_PAGE_SIZE, would
it be more accurate to use the later here?
> + 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);
> + }
>
> /*
> * Ignore any errors in setting up stimer clockevents
--
Vitaly
On Thu, Nov 12, 2020 at 04:51:09PM +0100, Vitaly Kuznetsov wrote:
> Wei Liu <[email protected]> writes:
>
> > 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.
> >
> > The suspend, resume and cleanup paths remain untouched because they are
> > not supported in this setup yet.
>
> What about adding BUG_ONs there then?
I generally avoid cluttering code if I'm sure it definitely does not
work.
In any case, adding BUG_ONs is not the right answer. Both hv_suspend and
hv_resume can return an error code. I would rather just do
if (hv_root_partition)
return -EPERM;
in both places.
And also make hv_is_hibernation_supported return false when Linux is the
root partition.
> > +
> > + if (hv_root_partition) {
> > + struct page *pg;
> > + void *src, *dst;
> > +
> > + /*
> > + * For the root partition, the hypervisor will set up its
> > + * hypercall page. The hypervisor guarantees it will not show
> > + * up in the root's address space. The root can't change the
> > + * location of the hypercall page.
> > + *
> > + * 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);
> > + BUG_ON(!(src && dst));
> > + memcpy(dst, src, PAGE_SIZE);
>
> Super-nit: while on x86 PAGE_SIZE always matches HV_HYP_PAGE_SIZE, would
> it be more accurate to use the later here?
Sure. That can be done.
Wei.
On Fri, Nov 13, 2020 at 03:33:33PM +0000, Wei Liu wrote:
> On Thu, Nov 12, 2020 at 04:51:09PM +0100, Vitaly Kuznetsov wrote:
> > Wei Liu <[email protected]> writes:
> >
> > > 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.
> > >
> > > The suspend, resume and cleanup paths remain untouched because they are
> > > not supported in this setup yet.
> >
> > What about adding BUG_ONs there then?
>
> I generally avoid cluttering code if I'm sure it definitely does not
> work.
>
> In any case, adding BUG_ONs is not the right answer. Both hv_suspend and
> hv_resume can return an error code. I would rather just do
>
> if (hv_root_partition)
> return -EPERM;
>
> in both places.
Correction: hv_resume is void, so I won't add that code snippet. But we
should still be fine because hv_suspend will have already failed in the
first place.
Wei.
Wei Liu <[email protected]> writes:
> On Fri, Nov 13, 2020 at 03:33:33PM +0000, Wei Liu wrote:
>> On Thu, Nov 12, 2020 at 04:51:09PM +0100, Vitaly Kuznetsov wrote:
>> > Wei Liu <[email protected]> writes:
>> >
>> > > 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.
>> > >
>> > > The suspend, resume and cleanup paths remain untouched because they are
>> > > not supported in this setup yet.
>> >
>> > What about adding BUG_ONs there then?
>>
>> I generally avoid cluttering code if I'm sure it definitely does not
>> work.
>>
>> In any case, adding BUG_ONs is not the right answer. Both hv_suspend and
>> hv_resume can return an error code. I would rather just do
>>
>> if (hv_root_partition)
>> return -EPERM;
>>
>> in both places.
>
> Correction: hv_resume is void, so I won't add that code snippet. But we
> should still be fine because hv_suspend will have already failed in the
> first place.
>
Works for me. I just very much prefer to get reports like "system
doesn't go to sleep" instead of "something crashes when I put my system
to sleep")
--
Vitaly