[PATCH v2 1/3] x86: provide an init_mem_mapping hypervisor hook

[PATCH v2 1/3] x86: provide an init_mem_mapping hypervisor hook

[Juergen Gross]

Provide a hook in hypervisor_x86 called after setting up initial
memory mapping.

This is needed e.g. by Xen HVM guests to map the hypervisor shared
info page.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/hypervisor.h | 10 ++++++++++
 arch/x86/mm/init.c                |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/hypervisor.h b/arch/x86/include/asm/hypervisor.h
index 21126155a739..0ead9dbb9130 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -43,6 +43,9 @@ struct hypervisor_x86 {
 
 	/* pin current vcpu to specified physical cpu (run rarely) */
 	void		(*pin_vcpu)(int);
+
+	/* called during init_mem_mapping() to setup early mappings. */
+	void		(*init_mem_mapping)(void);
 };
 
 extern const struct hypervisor_x86 *x86_hyper;
@@ -57,8 +60,15 @@ extern const struct hypervisor_x86 x86_hyper_kvm;
 extern void init_hypervisor_platform(void);
 extern bool hypervisor_x2apic_available(void);
 extern void hypervisor_pin_vcpu(int cpu);
+
+static inline void hypervisor_init_mem_mapping(void)
+{
+	if (x86_hyper && x86_hyper->init_mem_mapping)
+		x86_hyper->init_mem_mapping();
+}
 #else
 static inline void init_hypervisor_platform(void) { }
 static inline bool hypervisor_x2apic_available(void) { return false; }
+static inline void hypervisor_init_mem_mapping(void) { }
 #endif /* CONFIG_HYPERVISOR_GUEST */
 #endif /* _ASM_X86_HYPERVISOR_H */
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 673541eb3b3f..bf3f1065d6ad 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -18,6 +18,7 @@
 #include <asm/dma.h>		/* for MAX_DMA_PFN */
 #include <asm/microcode.h>
 #include <asm/kaslr.h>
+#include <asm/hypervisor.h>
 
 /*
  * We need to define the tracepoints somewhere, and tlb.c
@@ -636,6 +637,8 @@ void __init init_mem_mapping(void)
 	load_cr3(swapper_pg_dir);
 	__flush_tlb_all();
 
+	hypervisor_init_mem_mapping();
+
 	early_memtest(0, max_pfn_mapped << PAGE_SHIFT);
 }
 
-- 
2.12.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v2 2/3] xen: split up xen_hvm_init_shared_info()

[Juergen Gross]

Instead of calling xen_hvm_init_shared_info() on boot and resume split
it up into a boot time function searching for the pfn to use and a
mapping function doing the hypervisor mapping call.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/enlighten_hvm.c | 45 +++++++++++++++++++++++---------------------
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 87d791356ea9..d23531f5f17e 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -21,29 +21,9 @@
 #include "mmu.h"
 #include "smp.h"
 
-void __ref xen_hvm_init_shared_info(void)
+void xen_hvm_init_shared_info(void)
 {
 	struct xen_add_to_physmap xatp;
-	u64 pa;
-
-	if (HYPERVISOR_shared_info == &xen_dummy_shared_info) {
-		/*
-		 * Search for a free page starting at 4kB physical address.
-		 * Low memory is preferred to avoid an EPT large page split up
-		 * by the mapping.
-		 * Starting below X86_RESERVE_LOW (usually 64kB) is fine as
-		 * the BIOS used for HVM guests is well behaved and won't
-		 * clobber memory other than the first 4kB.
-		 */
-		for (pa = PAGE_SIZE;
-		     !e820__mapped_all(pa, pa + PAGE_SIZE, E820_TYPE_RAM) ||
-		     memblock_is_reserved(pa);
-		     pa += PAGE_SIZE)
-			;
-
-		memblock_reserve(pa, PAGE_SIZE);
-		HYPERVISOR_shared_info = __va(pa);
-	}
 
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
@@ -53,6 +33,28 @@ void __ref xen_hvm_init_shared_info(void)
 		BUG();
 }
 
+static void __init reserve_shared_info(void)
+{
+	u64 pa;
+
+	/*
+	 * Search for a free page starting at 4kB physical address.
+	 * Low memory is preferred to avoid an EPT large page split up
+	 * by the mapping.
+	 * Starting below X86_RESERVE_LOW (usually 64kB) is fine as
+	 * the BIOS used for HVM guests is well behaved and won't
+	 * clobber memory other than the first 4kB.
+	 */
+	for (pa = PAGE_SIZE;
+	     !e820__mapped_all(pa, pa + PAGE_SIZE, E820_TYPE_RAM) ||
+	     memblock_is_reserved(pa);
+	     pa += PAGE_SIZE)
+		;
+
+	memblock_reserve(pa, PAGE_SIZE);
+	HYPERVISOR_shared_info = __va(pa);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
@@ -153,6 +155,7 @@ static void __init xen_hvm_guest_init(void)
 
 	init_hvm_pv_info();
 
+	reserve_shared_info();
 	xen_hvm_init_shared_info();
 
 	/*
-- 
2.12.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v2 3/3] xen: fix hvm guest with kaslr enabled

[Juergen Gross]

A Xen HVM guest running with KASLR enabled will die rather soon today
due to the shared info page mapping is using va() too early. This was
introduced by commit a5d5f328b0e2baa5ee7c119fd66324eb79eeeb66 ("xen:
allocate page for shared info page from low memory").

In order to fix this use early_memremap() to get a temporary virtual
address for shared info until va() can be used safely.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/enlighten_hvm.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index d23531f5f17e..de503c225ae1 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -12,6 +12,7 @@
 #include <asm/setup.h>
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
+#include <asm/early_ioremap.h>
 
 #include <asm/xen/cpuid.h>
 #include <asm/xen/hypervisor.h>
@@ -21,6 +22,8 @@
 #include "mmu.h"
 #include "smp.h"
 
+static unsigned long shared_info_pfn;
+
 void xen_hvm_init_shared_info(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -28,7 +31,7 @@ void xen_hvm_init_shared_info(void)
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = virt_to_pfn(HYPERVISOR_shared_info);
+	xatp.gpfn = shared_info_pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 }
@@ -51,8 +54,16 @@ static void __init reserve_shared_info(void)
 	     pa += PAGE_SIZE)
 		;
 
+	shared_info_pfn = PHYS_PFN(pa);
+
 	memblock_reserve(pa, PAGE_SIZE);
-	HYPERVISOR_shared_info = __va(pa);
+	HYPERVISOR_shared_info = early_memremap(pa, PAGE_SIZE);
+}
+
+static void __init xen_hvm_init_mem_mapping(void)
+{
+	early_memunmap(HYPERVISOR_shared_info, PAGE_SIZE);
+	HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
 }
 
 static void __init init_hvm_pv_info(void)
@@ -221,5 +232,6 @@ const struct hypervisor_x86 x86_hyper_xen_hvm = {
 	.init_platform          = xen_hvm_guest_init,
 	.pin_vcpu               = xen_pin_vcpu,
 	.x2apic_available       = xen_x2apic_para_available,
+	.init_mem_mapping	= xen_hvm_init_mem_mapping,
 };
 EXPORT_SYMBOL(x86_hyper_xen_hvm);
-- 
2.12.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

[Juergen Gross]

On 28/07/17 12:23, Juergen Gross wrote:
> This patch series fixes a regression introduced in 4.13-rc1: A Xen
> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
> of __va() before kernel_randomize_memory() was called.
> 
> Changes in V2:
> - patch 1: test for x86_hyper being not NULL
> 
> Juergen Gross (3):
>   x86: provide an init_mem_mapping hypervisor hook
>   xen: split up xen_hvm_init_shared_info()
>   xen: fix hvm guest with kaslr enabled
> 
>  arch/x86/include/asm/hypervisor.h | 10 +++++++
>  arch/x86/mm/init.c                |  3 ++
>  arch/x86/xen/enlighten_hvm.c      | 59 ++++++++++++++++++++++++---------------
>  3 files changed, 50 insertions(+), 22 deletions(-)
> 

Could I have some feedback, please?

I'd like to get this regression fixed in 4.13.

In case nobody objects this week I'll just add the patches to the Xen
tree for rc5.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v2 3/3] xen: fix hvm guest with kaslr enabled

[Andrew Cooper]

On 28/07/17 11:23, Juergen Gross wrote:
> A Xen HVM guest running with KASLR enabled will die rather soon today
> due to the shared info page mapping is using va() too early. This was

As a minor grammar issue, either s/due to/because/ or s/mapping is
using/mapping using/

~Andrew

> introduced by commit a5d5f328b0e2baa5ee7c119fd66324eb79eeeb66 ("xen:
> allocate page for shared info page from low memory").


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

[Boris Ostrovsky]

On 08/08/2017 02:46 AM, Juergen Gross wrote:
> On 28/07/17 12:23, Juergen Gross wrote:
>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
>> of __va() before kernel_randomize_memory() was called.
>>
>> Changes in V2:
>> - patch 1: test for x86_hyper being not NULL
>>
>> Juergen Gross (3):
>>   x86: provide an init_mem_mapping hypervisor hook
>>   xen: split up xen_hvm_init_shared_info()
>>   xen: fix hvm guest with kaslr enabled
>>
>>  arch/x86/include/asm/hypervisor.h | 10 +++++++
>>  arch/x86/mm/init.c                |  3 ++
>>  arch/x86/xen/enlighten_hvm.c      | 59 ++++++++++++++++++++++++---------------
>>  3 files changed, 50 insertions(+), 22 deletions(-)
>>
> Could I have some feedback, please?
>
> I'd like to get this regression fixed in 4.13.
>
> In case nobody objects this week I'll just add the patches to the Xen
> tree for rc5.


As I said before I think .init_mem_mapping() could live in
x86_platform_ops() but this works too, so

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

But this still wants x86 maintainers' ACK.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

[Juergen Gross]

On 08/08/17 16:00, Boris Ostrovsky wrote:
> On 08/08/2017 02:46 AM, Juergen Gross wrote:
>> On 28/07/17 12:23, Juergen Gross wrote:
>>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
>>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
>>> of __va() before kernel_randomize_memory() was called.
>>>
>>> Changes in V2:
>>> - patch 1: test for x86_hyper being not NULL
>>>
>>> Juergen Gross (3):
>>>   x86: provide an init_mem_mapping hypervisor hook
>>>   xen: split up xen_hvm_init_shared_info()
>>>   xen: fix hvm guest with kaslr enabled
>>>
>>>  arch/x86/include/asm/hypervisor.h | 10 +++++++
>>>  arch/x86/mm/init.c                |  3 ++
>>>  arch/x86/xen/enlighten_hvm.c      | 59 ++++++++++++++++++++++++---------------
>>>  3 files changed, 50 insertions(+), 22 deletions(-)
>>>
>> Could I have some feedback, please?
>>
>> I'd like to get this regression fixed in 4.13.
>>
>> In case nobody objects this week I'll just add the patches to the Xen
>> tree for rc5.
> 
> 
> As I said before I think .init_mem_mapping() could live in
> x86_platform_ops() but this works too, so
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> But this still wants x86 maintainers' ACK.

x86 maintainers, could you please comment on at least patch 1?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

[Ingo Molnar]

* Juergen Gross <jgross@suse.com> wrote:

> On 08/08/17 16:00, Boris Ostrovsky wrote:
> > On 08/08/2017 02:46 AM, Juergen Gross wrote:
> >> On 28/07/17 12:23, Juergen Gross wrote:
> >>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
> >>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
> >>> of __va() before kernel_randomize_memory() was called.
> >>>
> >>> Changes in V2:
> >>> - patch 1: test for x86_hyper being not NULL
> >>>
> >>> Juergen Gross (3):
> >>>   x86: provide an init_mem_mapping hypervisor hook
> >>>   xen: split up xen_hvm_init_shared_info()
> >>>   xen: fix hvm guest with kaslr enabled
> >>>
> >>>  arch/x86/include/asm/hypervisor.h | 10 +++++++
> >>>  arch/x86/mm/init.c                |  3 ++
> >>>  arch/x86/xen/enlighten_hvm.c      | 59 ++++++++++++++++++++++++---------------
> >>>  3 files changed, 50 insertions(+), 22 deletions(-)
> >>>
> >> Could I have some feedback, please?
> >>
> >> I'd like to get this regression fixed in 4.13.
> >>
> >> In case nobody objects this week I'll just add the patches to the Xen
> >> tree for rc5.
> > 
> > 
> > As I said before I think .init_mem_mapping() could live in
> > x86_platform_ops() but this works too, so
> > 
> > Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > 
> > But this still wants x86 maintainers' ACK.
> 
> x86 maintainers, could you please comment on at least patch 1?

LGTM:

Acked-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v2 0/3] fix xen hvm guest with kaslr enabled

[Juergen Gross]

This patch series fixes a regression introduced in 4.13-rc1: A Xen
HVM guest with KASLR enabled wouldn't boot any longer due to the usage
of __va() before kernel_randomize_memory() was called.

Changes in V2:
- patch 1: test for x86_hyper being not NULL

Juergen Gross (3):
  x86: provide an init_mem_mapping hypervisor hook
  xen: split up xen_hvm_init_shared_info()
  xen: fix hvm guest with kaslr enabled

 arch/x86/include/asm/hypervisor.h | 10 +++++++
 arch/x86/mm/init.c                |  3 ++
 arch/x86/xen/enlighten_hvm.c      | 59 ++++++++++++++++++++++++---------------
 3 files changed, 50 insertions(+), 22 deletions(-)

-- 
2.12.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel