[RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

Sorry for the delay between this version and the last -- it was mostly
due to holidays and everyone being focused on security bug mitigation
issues. Here are the links to the previous email threads in case it is
helpful:

V3: https://lkml.org/lkml/2017/12/12/1230
V2: https://lkml.org/lkml/2017/12/7/1624
V1: https://lkml.org/lkml/2017/11/28/1280

Changes from v3:

 * Implemented Juergen's suggestion for refactoring and moving the PVH
   code so that CONFIG_XEN is no longer required for booting KVM guests
   via the PVH entry point.
   Functionally, nothing has changed from V3 really, but the patches
   look completely different now because of all the code movement and
   refactoring. Some of these patches can be combined, but I've left
   them very small in some cases to make the refactoring and code
   movement easier to review.
   My approach for refactoring has been to create a PVH entry layer that
   still has understanding and knowledge about Xen vs non-Xen guest types
   so that it can make run time decisions to handle either case, as
   opposed to going all the way and re-writing it to be a completely
   hypervisor agnostic and architecturally pure layer that is separate
   from guest type details. The latter seemed a bit overkill in this
   situation. And I've handled the complexity of having to support
   Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
   pair of xen specific __weak routines that can be overridden in kernels
   that support Xen guests. Importantly, the __weak routines are for
   xen specific code only (not generic "guest type" specific code) so
   there is no clashing between xen version of the strong routine and,
   say, a KVM version of the same routine. But I'm sure there are many
   ways to skin this cat, so I'm open to alternate suggestions if there
   is a compelling reason for not using __weak in this situation.

Changes from v2:

 * All structures (including memory map table entries) are padded and
   aligned to an 8 byte boundary.

 * Removed the "packed" attributes and made changes to comments as
   suggested by Jan.

Changes from v1:

 * Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the
   e820 map instead of using the second module entry to pass the table.

 * Cleaned things up a bit to reduce the number of xen vs non-xen special
   cases.

Maran Wilson (7):
      xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH
      xen/pvh: Move PVH entry code out of Xen specific tree
      xen/pvh: Create a new file for Xen specific PVH code
      xen/pvh: Move Xen specific PVH VM initialization out of common code
      xen/pvh: Move Xen code for getting mem map via hcall out of common file
      xen/pvh: Add memory map pointer to hvm_start_info struct
      KVM: x86: Allow Qemu/KVM to use PVH entry point

 MAINTAINERS                            |   1 +
 arch/x86/Kbuild                        |   3 +
 arch/x86/Kconfig                       |   8 ++
 arch/x86/kernel/head_64.S              |   4 +-
 arch/x86/pvh-head.S                    | 161 +++++++++++++++++++++++
 arch/x86/pvh.c                         | 130 ++++++++++++++++++
 arch/x86/xen/Kconfig                   |   3 +-
 arch/x86/xen/Makefile                  |   1 -
 arch/x86/xen/enlighten_pvh.c           |  87 +++---------
 arch/x86/xen/xen-pvh.S                 | 161 -----------------------
 include/xen/interface/hvm/start_info.h |  50 ++++++-
 11 files changed, 374 insertions(+), 235 deletions(-)

[RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

Sorry for the delay between this version and the last -- it was mostly
due to holidays and everyone being focused on security bug mitigation
issues. Here are the links to the previous email threads in case it is
helpful:

V3: https://lkml.org/lkml/2017/12/12/1230
V2: https://lkml.org/lkml/2017/12/7/1624
V1: https://lkml.org/lkml/2017/11/28/1280

Changes from v3:

 * Implemented Juergen's suggestion for refactoring and moving the PVH
   code so that CONFIG_XEN is no longer required for booting KVM guests
   via the PVH entry point.
   Functionally, nothing has changed from V3 really, but the patches
   look completely different now because of all the code movement and
   refactoring. Some of these patches can be combined, but I've left
   them very small in some cases to make the refactoring and code
   movement easier to review.
   My approach for refactoring has been to create a PVH entry layer that
   still has understanding and knowledge about Xen vs non-Xen guest types
   so that it can make run time decisions to handle either case, as
   opposed to going all the way and re-writing it to be a completely
   hypervisor agnostic and architecturally pure layer that is separate
   from guest type details. The latter seemed a bit overkill in this
   situation. And I've handled the complexity of having to support
   Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
   pair of xen specific __weak routines that can be overridden in kernels
   that support Xen guests. Importantly, the __weak routines are for
   xen specific code only (not generic "guest type" specific code) so
   there is no clashing between xen version of the strong routine and,
   say, a KVM version of the same routine. But I'm sure there are many
   ways to skin this cat, so I'm open to alternate suggestions if there
   is a compelling reason for not using __weak in this situation.

Changes from v2:

 * All structures (including memory map table entries) are padded and
   aligned to an 8 byte boundary.

 * Removed the "packed" attributes and made changes to comments as
   suggested by Jan.

Changes from v1:

 * Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the
   e820 map instead of using the second module entry to pass the table.

 * Cleaned things up a bit to reduce the number of xen vs non-xen special
   cases.

Maran Wilson (7):
      xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH
      xen/pvh: Move PVH entry code out of Xen specific tree
      xen/pvh: Create a new file for Xen specific PVH code
      xen/pvh: Move Xen specific PVH VM initialization out of common code
      xen/pvh: Move Xen code for getting mem map via hcall out of common file
      xen/pvh: Add memory map pointer to hvm_start_info struct
      KVM: x86: Allow Qemu/KVM to use PVH entry point

 MAINTAINERS                            |   1 +
 arch/x86/Kbuild                        |   3 +
 arch/x86/Kconfig                       |   8 ++
 arch/x86/kernel/head_64.S              |   4 +-
 arch/x86/pvh-head.S                    | 161 +++++++++++++++++++++++
 arch/x86/pvh.c                         | 130 ++++++++++++++++++
 arch/x86/xen/Kconfig                   |   3 +-
 arch/x86/xen/Makefile                  |   1 -
 arch/x86/xen/enlighten_pvh.c           |  87 +++---------
 arch/x86/xen/xen-pvh.S                 | 161 -----------------------
 include/xen/interface/hvm/start_info.h |  50 ++++++-
 11 files changed, 374 insertions(+), 235 deletions(-)


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

[RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

In order to pave the way for hypervisors other then Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from CONFIG_XEN.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/Kconfig          | 8 ++++++++
 arch/x86/kernel/head_64.S | 4 ++--
 arch/x86/xen/Kconfig      | 3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..fa7cd0305125 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,14 @@ config KVM_GUEST
 	  underlying device model, the host provides the guest with
 	  timing infrastructure such as time of day, and system time
 
+config PVH
+	bool "Support for running PVH guests"
+	depends on KVM_GUEST || XEN
+	def_bool n
+	---help---
+	  This option enables the PVH entry point for guest virtual machines
+	  as specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
 	bool "Enable debug information for KVM Guests in debugfs"
 	depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 0f545b3cf926..fc9f678c6413 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -41,7 +41,7 @@
 
 #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
 PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
 #endif
@@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
 
 	.data
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 NEXT_PGD_PAGE(init_top_pgt)
 	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
 	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index f605825a04ab..021c8591c3c0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -77,8 +77,9 @@ config XEN_DEBUG_FS
 	  Enabling this option may incur a significant performance overhead.
 
 config XEN_PVH
-	bool "Support for running as a PVH guest"
+	bool "Support for running as a Xen PVH guest"
 	depends on XEN && XEN_PVHVM && ACPI
 	# Pre-built page tables are not ready to handle 5-level paging.
 	depends on !X86_5LEVEL
+	select PVH
 	def_bool n
-- 
2.16.1

[RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

In order to pave the way for hypervisors other then Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from CONFIG_XEN.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/Kconfig          | 8 ++++++++
 arch/x86/kernel/head_64.S | 4 ++--
 arch/x86/xen/Kconfig      | 3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..fa7cd0305125 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,14 @@ config KVM_GUEST
 	  underlying device model, the host provides the guest with
 	  timing infrastructure such as time of day, and system time
 
+config PVH
+	bool "Support for running PVH guests"
+	depends on KVM_GUEST || XEN
+	def_bool n
+	---help---
+	  This option enables the PVH entry point for guest virtual machines
+	  as specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
 	bool "Enable debug information for KVM Guests in debugfs"
 	depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 0f545b3cf926..fc9f678c6413 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -41,7 +41,7 @@
 
 #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
 PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
 #endif
@@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
 
 	.data
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 NEXT_PGD_PAGE(init_top_pgt)
 	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
 	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index f605825a04ab..021c8591c3c0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -77,8 +77,9 @@ config XEN_DEBUG_FS
 	  Enabling this option may incur a significant performance overhead.
 
 config XEN_PVH
-	bool "Support for running as a PVH guest"
+	bool "Support for running as a Xen PVH guest"
 	depends on XEN && XEN_PVHVM && ACPI
 	# Pre-built page tables are not ready to handle 5-level paging.
 	depends on !X86_5LEVEL
+	select PVH
 	def_bool n
-- 
2.16.1


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

[RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files sitting at a higher level in the tree.

This patch is not introducing any code or functional changes, just moving
files from one location to another.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 MAINTAINERS                             | 1 +
 arch/x86/Kbuild                         | 3 +++
 arch/x86/{xen/xen-pvh.S => pvh-head.S}  | 0
 arch/x86/{xen/enlighten_pvh.c => pvh.c} | 0
 arch/x86/xen/Makefile                   | 2 --
 5 files changed, 4 insertions(+), 2 deletions(-)
 rename arch/x86/{xen/xen-pvh.S => pvh-head.S} (100%)
 rename arch/x86/{xen/enlighten_pvh.c => pvh.c} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..dc89f3a279bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15210,6 +15210,7 @@ L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 S:	Supported
 F:	arch/x86/xen/
+F:	arch/x86/*pvh*
 F:	drivers/*/xen-*front.c
 F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 0038a2d10a7a..a4e5e3d348dc 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,6 +7,9 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
+obj-$(CONFIG_XEN_PVH) += pvh.o
+obj-$(CONFIG_XEN_PVH) += pvh-head.o
+
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
 
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/pvh-head.S
similarity index 100%
rename from arch/x86/xen/xen-pvh.S
rename to arch/x86/pvh-head.S
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/pvh.c
similarity index 100%
rename from arch/x86/xen/enlighten_pvh.c
rename to arch/x86/pvh.c
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index d83cb5478f54..7e8145b33997 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,7 +21,6 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
-obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
@@ -33,4 +32,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
 obj-$(CONFIG_XEN_DOM0)		+= vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)		+= efi.o
-obj-$(CONFIG_XEN_PVH)	 	+= xen-pvh.o
-- 
2.16.1

[RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files sitting at a higher level in the tree.

This patch is not introducing any code or functional changes, just moving
files from one location to another.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 MAINTAINERS                             | 1 +
 arch/x86/Kbuild                         | 3 +++
 arch/x86/{xen/xen-pvh.S => pvh-head.S}  | 0
 arch/x86/{xen/enlighten_pvh.c => pvh.c} | 0
 arch/x86/xen/Makefile                   | 2 --
 5 files changed, 4 insertions(+), 2 deletions(-)
 rename arch/x86/{xen/xen-pvh.S => pvh-head.S} (100%)
 rename arch/x86/{xen/enlighten_pvh.c => pvh.c} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..dc89f3a279bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15210,6 +15210,7 @@ L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 S:	Supported
 F:	arch/x86/xen/
+F:	arch/x86/*pvh*
 F:	drivers/*/xen-*front.c
 F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 0038a2d10a7a..a4e5e3d348dc 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,6 +7,9 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
+obj-$(CONFIG_XEN_PVH) += pvh.o
+obj-$(CONFIG_XEN_PVH) += pvh-head.o
+
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
 
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/pvh-head.S
similarity index 100%
rename from arch/x86/xen/xen-pvh.S
rename to arch/x86/pvh-head.S
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/pvh.c
similarity index 100%
rename from arch/x86/xen/enlighten_pvh.c
rename to arch/x86/pvh.c
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index d83cb5478f54..7e8145b33997 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,7 +21,6 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
-obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
@@ -33,4 +32,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
 obj-$(CONFIG_XEN_DOM0)		+= vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)		+= efi.o
-obj-$(CONFIG_XEN_PVH)	 	+= xen-pvh.o
-- 
2.16.1


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

[RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/pvh.c               |  1 -
 arch/x86/xen/Makefile        |  1 +
 arch/x86/xen/enlighten_pvh.c | 11 +++++++++++
 3 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 436c4f003e17..b56cb5e7d6ac 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -19,7 +19,6 @@
  * xen_pvh and pvh_bootparams need to live in data segment since they
  * are used after startup_{32|64}, which clear .bss, are invoked.
  */
-bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
 
 struct hvm_start_info pvh_start_info;
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 7e8145b33997..ef6481a83768 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,6 +21,7 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
+obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
new file mode 100644
index 000000000000..4b4e9cc78b8a
--- /dev/null
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -0,0 +1,11 @@
+#include <linux/types.h>
+
+/*
+ * PVH variables.
+ *
+ * The variables xen_pvh and pvh_bootparams need to live in the data segment
+ * since they are used after startup_{32|64} is invoked, which will clear the
+ * .bss segment.
+ */
+bool xen_pvh __attribute__((section(".data"))) = 0;
+
-- 
2.16.1

[RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/pvh.c               |  1 -
 arch/x86/xen/Makefile        |  1 +
 arch/x86/xen/enlighten_pvh.c | 11 +++++++++++
 3 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 436c4f003e17..b56cb5e7d6ac 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -19,7 +19,6 @@
  * xen_pvh and pvh_bootparams need to live in data segment since they
  * are used after startup_{32|64}, which clear .bss, are invoked.
  */
-bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
 
 struct hvm_start_info pvh_start_info;
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 7e8145b33997..ef6481a83768 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,6 +21,7 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
+obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
new file mode 100644
index 000000000000..4b4e9cc78b8a
--- /dev/null
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -0,0 +1,11 @@
+#include <linux/types.h>
+
+/*
+ * PVH variables.
+ *
+ * The variables xen_pvh and pvh_bootparams need to live in the data segment
+ * since they are used after startup_{32|64} is invoked, which will clear the
+ * .bss segment.
+ */
+bool xen_pvh __attribute__((section(".data"))) = 0;
+
-- 
2.16.1


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

[RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Moving it out of the common file
is going to allow us to compile kernels in the future without CONFIG_XEN
that are still capable of being booted as a Qemu/KVM guest via the PVH
entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/pvh.c               | 28 ++++++++++++++++++++--------
 arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++-
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index b56cb5e7d6ac..2d7a7f4958cb 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
 	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
 }
 
+/*
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide the required override for this routine.
+ */
+void __init __weak xen_pvh_init(void)
+{
+	xen_raw_printk("Error: Missing xen PVH initialization\n");
+	BUG();
+}
+
+/*
+ * When we add support for other hypervisors like Qemu/KVM, this routine can
+ * selectively invoke the appropriate initialization based on guest type.
+ */
+static void hypervisor_specific_init(void)
+{
+	xen_pvh_init();
+}
+
 /*
  * This routine (and those that it might call) should not use
  * anything that lives in .bss since that segment will be cleared later.
  */
 void __init xen_prepare_pvh(void)
 {
-	u32 msr;
-	u64 pfn;
-
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	xen_pvh = 1;
-
-	msr = cpuid_ebx(xen_cpuid_base() + 2);
-	pfn = __pa(hypercall_page);
-	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+	hypervisor_specific_init();
 
 	init_pvh_bootparams();
 }
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 4b4e9cc78b8a..833c441a20df 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,4 +1,9 @@
-#include <linux/types.h>
+#include <linux/acpi.h>
+
+#include <asm/io_apic.h>
+
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
 
 /*
  * PVH variables.
@@ -9,3 +14,14 @@
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 
+void __init xen_pvh_init(void)
+{
+	u32 msr;
+	u64 pfn;
+
+	xen_pvh = 1;
+
+	msr = cpuid_ebx(xen_cpuid_base() + 2);
+	pfn = __pa(hypercall_page);
+	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+}
-- 
2.16.1

[RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Moving it out of the common file
is going to allow us to compile kernels in the future without CONFIG_XEN
that are still capable of being booted as a Qemu/KVM guest via the PVH
entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/pvh.c               | 28 ++++++++++++++++++++--------
 arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++-
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index b56cb5e7d6ac..2d7a7f4958cb 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
 	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
 }
 
+/*
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide the required override for this routine.
+ */
+void __init __weak xen_pvh_init(void)
+{
+	xen_raw_printk("Error: Missing xen PVH initialization\n");
+	BUG();
+}
+
+/*
+ * When we add support for other hypervisors like Qemu/KVM, this routine can
+ * selectively invoke the appropriate initialization based on guest type.
+ */
+static void hypervisor_specific_init(void)
+{
+	xen_pvh_init();
+}
+
 /*
  * This routine (and those that it might call) should not use
  * anything that lives in .bss since that segment will be cleared later.
  */
 void __init xen_prepare_pvh(void)
 {
-	u32 msr;
-	u64 pfn;
-
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	xen_pvh = 1;
-
-	msr = cpuid_ebx(xen_cpuid_base() + 2);
-	pfn = __pa(hypercall_page);
-	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+	hypervisor_specific_init();
 
 	init_pvh_bootparams();
 }
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 4b4e9cc78b8a..833c441a20df 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,4 +1,9 @@
-#include <linux/types.h>
+#include <linux/acpi.h>
+
+#include <asm/io_apic.h>
+
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
 
 /*
  * PVH variables.
@@ -9,3 +14,14 @@
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 
+void __init xen_pvh_init(void)
+{
+	u32 msr;
+	u64 pfn;
+
+	xen_pvh = 1;
+
+	msr = cpuid_ebx(xen_cpuid_base() + 2);
+	pfn = __pa(hypercall_page);
+	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+}
-- 
2.16.1


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

[RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
a new mechanism will be added that allows the guest to get the memory
map without needing to use hypercalls.

For Xen guests, the hypercall approach will still be supported. In
preparation for adding support for other hypervisors, we can move the
code that uses hypercalls into the Xen specific file. This will allow us
to compile kernels in the future without CONFIG_XEN that are still capable
of being booted as a Qemu/KVM guest via the PVH entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/pvh.c               | 28 ++++++++++++++--------------
 arch/x86/xen/enlighten_pvh.c | 20 ++++++++++++++++++++
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 2d7a7f4958cb..6e9f6a6e97b3 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -7,9 +7,6 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
-#include <asm/xen/interface.h>
-#include <asm/xen/hypercall.h>
-
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -24,21 +21,24 @@ struct boot_params pvh_bootparams __attribute__((section(".data")));
 struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
+/*
+ * Xen guests are able to obtain the memory map from the hypervisor via the
+ * HYPERVISOR_memory_op hypercall.
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide an override for this routine to do
+ * just that.
+ */
+void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
+{
+	xen_raw_printk("Error: Could not find memory map\n");
+	BUG();
+}
+
 static void __init init_pvh_bootparams(void)
 {
-	struct xen_memory_map memmap;
-	int rc;
-
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
-	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
-	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
-	if (rc) {
-		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-		BUG();
-	}
-	pvh_bootparams.e820_entries = memmap.nr_entries;
+	mem_map_via_hcall(&pvh_bootparams);
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 833c441a20df..3a830caef8ee 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,10 +1,15 @@
 #include <linux/acpi.h>
 
+#include <xen/hvc-console.h>
+
 #include <asm/io_apic.h>
+#include <asm/e820/api.h>
 
 #include <asm/xen/interface.h>
 #include <asm/xen/hypercall.h>
 
+#include <xen/interface/memory.h>
+
 /*
  * PVH variables.
  *
@@ -25,3 +30,18 @@ void __init xen_pvh_init(void)
 	pfn = __pa(hypercall_page);
 	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 }
+
+void __init mem_map_via_hcall(struct boot_params *boot_params_p)
+{
+	struct xen_memory_map memmap;
+	int rc;
+
+	memmap.nr_entries = ARRAY_SIZE(boot_params_p->e820_table);
+	set_xen_guest_handle(memmap.buffer, boot_params_p->e820_table);
+	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
+	if (rc) {
+		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+		BUG();
+	}
+	boot_params_p->e820_entries = memmap.nr_entries;
+}
-- 
2.16.1

[RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
a new mechanism will be added that allows the guest to get the memory
map without needing to use hypercalls.

For Xen guests, the hypercall approach will still be supported. In
preparation for adding support for other hypervisors, we can move the
code that uses hypercalls into the Xen specific file. This will allow us
to compile kernels in the future without CONFIG_XEN that are still capable
of being booted as a Qemu/KVM guest via the PVH entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/pvh.c               | 28 ++++++++++++++--------------
 arch/x86/xen/enlighten_pvh.c | 20 ++++++++++++++++++++
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 2d7a7f4958cb..6e9f6a6e97b3 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -7,9 +7,6 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
-#include <asm/xen/interface.h>
-#include <asm/xen/hypercall.h>
-
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -24,21 +21,24 @@ struct boot_params pvh_bootparams __attribute__((section(".data")));
 struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
+/*
+ * Xen guests are able to obtain the memory map from the hypervisor via the
+ * HYPERVISOR_memory_op hypercall.
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide an override for this routine to do
+ * just that.
+ */
+void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
+{
+	xen_raw_printk("Error: Could not find memory map\n");
+	BUG();
+}
+
 static void __init init_pvh_bootparams(void)
 {
-	struct xen_memory_map memmap;
-	int rc;
-
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
-	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
-	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
-	if (rc) {
-		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-		BUG();
-	}
-	pvh_bootparams.e820_entries = memmap.nr_entries;
+	mem_map_via_hcall(&pvh_bootparams);
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 833c441a20df..3a830caef8ee 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,10 +1,15 @@
 #include <linux/acpi.h>
 
+#include <xen/hvc-console.h>
+
 #include <asm/io_apic.h>
+#include <asm/e820/api.h>
 
 #include <asm/xen/interface.h>
 #include <asm/xen/hypercall.h>
 
+#include <xen/interface/memory.h>
+
 /*
  * PVH variables.
  *
@@ -25,3 +30,18 @@ void __init xen_pvh_init(void)
 	pfn = __pa(hypercall_page);
 	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 }
+
+void __init mem_map_via_hcall(struct boot_params *boot_params_p)
+{
+	struct xen_memory_map memmap;
+	int rc;
+
+	memmap.nr_entries = ARRAY_SIZE(boot_params_p->e820_table);
+	set_xen_guest_handle(memmap.buffer, boot_params_p->e820_table);
+	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
+	if (rc) {
+		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+		BUG();
+	}
+	boot_params_p->e820_entries = memmap.nr_entries;
+}
-- 
2.16.1


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

[RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 include/xen/interface/hvm/start_info.h | 50 +++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/hvm/start_info.h b/include/xen/interface/hvm/start_info.h
index 648415976ead..80cfbd35c1af 100644
--- a/include/xen/interface/hvm/start_info.h
+++ b/include/xen/interface/hvm/start_info.h
@@ -33,7 +33,7 @@
  *    | magic          | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *    |                | ("xEn3" with the 0x80 bit of the "E" set).
  *  4 +----------------+
- *    | version        | Version of this structure. Current version is 0. New
+ *    | version        | Version of this structure. Current version is 1. New
  *    |                | versions are guaranteed to be backwards-compatible.
  *  8 +----------------+
  *    | flags          | SIF_xxx flags.
@@ -48,6 +48,15 @@
  * 32 +----------------+
  *    | rsdp_paddr     | Physical address of the RSDP ACPI data structure.
  * 40 +----------------+
+ *    | memmap_paddr   | Physical address of the (optional) memory map. Only
+ *    |                | present in version 1 and newer of the structure.
+ * 48 +----------------+
+ *    | memmap_entries | Number of entries in the memory map table. Only
+ *    |                | present in version 1 and newer of the structure.
+ *    |                | Zero if there is no memory map being provided.
+ * 52 +----------------+
+ *    | reserved       | Version 1 and newer only.
+ * 56 +----------------+
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,10 +71,34 @@
  *    | reserved       |
  * 32 +----------------+
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 +----------------+
+ *    | addr           | Base address
+ *  8 +----------------+
+ *    | size           | Size of mapping in bytes
+ * 16 +----------------+
+ *    | type           | Type of mapping as defined between the hypervisor
+ *    |                | and guest it's starting. E820_TYPE_xxx, for example.
+ * 20 +----------------|
+ *    | reserved       |
+ * 24 +----------------+
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:
+ *
+ * Version 1:	Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ *		padding) to the end of the hvm_start_info struct. These new
+ *		fields can be used to pass a memory map to the guest. The
+ *		memory map is optional and so guests that understand version 1
+ *		of the structure must check that memmap_entries is non-zero
+ *		before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
@@ -86,6 +119,14 @@ struct hvm_start_info {
     uint64_t cmdline_paddr;     /* Physical address of the command line.     */
     uint64_t rsdp_paddr;        /* Physical address of the RSDP ACPI data    */
                                 /* structure.                                */
+    uint64_t memmap_paddr;	/* Physical address of an array of           */
+				/* hvm_memmap_table_entry. Only present in   */
+				/* version 1 and newer of the structure      */
+    uint32_t memmap_entries;	/* Number of entries in the memmap table.    */
+				/* Only present in version 1 and newer of    */
+				/* the structure. Value will be zero if      */
+				/* there is no memory map being provided.    */
+    uint32_t reserved;
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +136,11 @@ struct hvm_modlist_entry {
     uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+    uint64_t addr;		/* Base address of the memory region         */
+    uint64_t size;		/* Size of the memory region in bytes        */
+    uint32_t type;		/* Mapping type                              */
+    uint32_t reserved;
+};
+
 #endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
-- 
2.16.1

[RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 include/xen/interface/hvm/start_info.h | 50 +++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/hvm/start_info.h b/include/xen/interface/hvm/start_info.h
index 648415976ead..80cfbd35c1af 100644
--- a/include/xen/interface/hvm/start_info.h
+++ b/include/xen/interface/hvm/start_info.h
@@ -33,7 +33,7 @@
  *    | magic          | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *    |                | ("xEn3" with the 0x80 bit of the "E" set).
  *  4 +----------------+
- *    | version        | Version of this structure. Current version is 0. New
+ *    | version        | Version of this structure. Current version is 1. New
  *    |                | versions are guaranteed to be backwards-compatible.
  *  8 +----------------+
  *    | flags          | SIF_xxx flags.
@@ -48,6 +48,15 @@
  * 32 +----------------+
  *    | rsdp_paddr     | Physical address of the RSDP ACPI data structure.
  * 40 +----------------+
+ *    | memmap_paddr   | Physical address of the (optional) memory map. Only
+ *    |                | present in version 1 and newer of the structure.
+ * 48 +----------------+
+ *    | memmap_entries | Number of entries in the memory map table. Only
+ *    |                | present in version 1 and newer of the structure.
+ *    |                | Zero if there is no memory map being provided.
+ * 52 +----------------+
+ *    | reserved       | Version 1 and newer only.
+ * 56 +----------------+
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,10 +71,34 @@
  *    | reserved       |
  * 32 +----------------+
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 +----------------+
+ *    | addr           | Base address
+ *  8 +----------------+
+ *    | size           | Size of mapping in bytes
+ * 16 +----------------+
+ *    | type           | Type of mapping as defined between the hypervisor
+ *    |                | and guest it's starting. E820_TYPE_xxx, for example.
+ * 20 +----------------|
+ *    | reserved       |
+ * 24 +----------------+
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:
+ *
+ * Version 1:	Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ *		padding) to the end of the hvm_start_info struct. These new
+ *		fields can be used to pass a memory map to the guest. The
+ *		memory map is optional and so guests that understand version 1
+ *		of the structure must check that memmap_entries is non-zero
+ *		before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
@@ -86,6 +119,14 @@ struct hvm_start_info {
     uint64_t cmdline_paddr;     /* Physical address of the command line.     */
     uint64_t rsdp_paddr;        /* Physical address of the RSDP ACPI data    */
                                 /* structure.                                */
+    uint64_t memmap_paddr;	/* Physical address of an array of           */
+				/* hvm_memmap_table_entry. Only present in   */
+				/* version 1 and newer of the structure      */
+    uint32_t memmap_entries;	/* Number of entries in the memmap table.    */
+				/* Only present in version 1 and newer of    */
+				/* the structure. Value will be zero if      */
+				/* there is no memory map being provided.    */
+    uint32_t reserved;
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +136,11 @@ struct hvm_modlist_entry {
     uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+    uint64_t addr;		/* Base address of the memory region         */
+    uint64_t size;		/* Size of the memory region in bytes        */
+    uint32_t type;		/* Mapping type                              */
+    uint32_t reserved;
+};
+
 #endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
-- 
2.16.1


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

[RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch enables Qemu to use that same entry point for booting KVM
guests.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/Kbuild |  4 ++--
 arch/x86/pvh.c  | 43 ++++++++++++++++++++++++++++++++-----------
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index a4e5e3d348dc..e9dc0f1c9d32 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,8 +7,8 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
-obj-$(CONFIG_XEN_PVH) += pvh.o
-obj-$(CONFIG_XEN_PVH) += pvh-head.o
+obj-$(CONFIG_PVH) += pvh.o
+obj-$(CONFIG_PVH) += pvh-head.o
 
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 6e9f6a6e97b3..97042d11342f 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -7,6 +7,9 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
+
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -34,11 +37,28 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
 	BUG();
 }
 
-static void __init init_pvh_bootparams(void)
+static void __init init_pvh_bootparams(bool xen_guest)
 {
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	mem_map_via_hcall(&pvh_bootparams);
+	if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
+		struct hvm_memmap_table_entry *ep;
+		int i;
+
+		ep = __va(pvh_start_info.memmap_paddr);
+		pvh_bootparams.e820_entries = pvh_start_info.memmap_entries;
+
+		for (i = 0; i < pvh_bootparams.e820_entries ; i++, ep++) {
+			pvh_bootparams.e820_table[i].addr = ep->addr;
+			pvh_bootparams.e820_table[i].size = ep->size;
+			pvh_bootparams.e820_table[i].type = ep->type;
+		}
+	} else if (xen_guest) {
+		mem_map_via_hcall(&pvh_bootparams);
+	} else {
+		/* Non-xen guests are not supported by version 0 */
+		BUG();
+	}
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
@@ -69,7 +89,7 @@ static void __init init_pvh_bootparams(void)
 	 * environment (i.e. hardware_subarch 0).
 	 */
 	pvh_bootparams.hdr.version = 0x212;
-	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+	pvh_bootparams.hdr.type_of_loader = ((xen_guest ? 0x9 : 0xb) << 4) | 0;
 }
 
 /*
@@ -82,13 +102,10 @@ void __init __weak xen_pvh_init(void)
 	BUG();
 }
 
-/*
- * When we add support for other hypervisors like Qemu/KVM, this routine can
- * selectively invoke the appropriate initialization based on guest type.
- */
-static void hypervisor_specific_init(void)
+static void hypervisor_specific_init(bool xen_guest)
 {
-	xen_pvh_init();
+	if (xen_guest)
+		xen_pvh_init();
 }
 
 /*
@@ -97,13 +114,17 @@ static void hypervisor_specific_init(void)
  */
 void __init xen_prepare_pvh(void)
 {
+
+	u32 msr = xen_cpuid_base();
+	bool xen_guest = !!msr;
+
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	hypervisor_specific_init();
+	hypervisor_specific_init(xen_guest);
 
-	init_pvh_bootparams();
+	init_pvh_bootparams(xen_guest);
 }
-- 
2.16.1

[RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch enables Qemu to use that same entry point for booting KVM
guests.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/Kbuild |  4 ++--
 arch/x86/pvh.c  | 43 ++++++++++++++++++++++++++++++++-----------
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index a4e5e3d348dc..e9dc0f1c9d32 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,8 +7,8 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
-obj-$(CONFIG_XEN_PVH) += pvh.o
-obj-$(CONFIG_XEN_PVH) += pvh-head.o
+obj-$(CONFIG_PVH) += pvh.o
+obj-$(CONFIG_PVH) += pvh-head.o
 
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 6e9f6a6e97b3..97042d11342f 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -7,6 +7,9 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
+
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -34,11 +37,28 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
 	BUG();
 }
 
-static void __init init_pvh_bootparams(void)
+static void __init init_pvh_bootparams(bool xen_guest)
 {
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	mem_map_via_hcall(&pvh_bootparams);
+	if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
+		struct hvm_memmap_table_entry *ep;
+		int i;
+
+		ep = __va(pvh_start_info.memmap_paddr);
+		pvh_bootparams.e820_entries = pvh_start_info.memmap_entries;
+
+		for (i = 0; i < pvh_bootparams.e820_entries ; i++, ep++) {
+			pvh_bootparams.e820_table[i].addr = ep->addr;
+			pvh_bootparams.e820_table[i].size = ep->size;
+			pvh_bootparams.e820_table[i].type = ep->type;
+		}
+	} else if (xen_guest) {
+		mem_map_via_hcall(&pvh_bootparams);
+	} else {
+		/* Non-xen guests are not supported by version 0 */
+		BUG();
+	}
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
@@ -69,7 +89,7 @@ static void __init init_pvh_bootparams(void)
 	 * environment (i.e. hardware_subarch 0).
 	 */
 	pvh_bootparams.hdr.version = 0x212;
-	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+	pvh_bootparams.hdr.type_of_loader = ((xen_guest ? 0x9 : 0xb) << 4) | 0;
 }
 
 /*
@@ -82,13 +102,10 @@ void __init __weak xen_pvh_init(void)
 	BUG();
 }
 
-/*
- * When we add support for other hypervisors like Qemu/KVM, this routine can
- * selectively invoke the appropriate initialization based on guest type.
- */
-static void hypervisor_specific_init(void)
+static void hypervisor_specific_init(bool xen_guest)
 {
-	xen_pvh_init();
+	if (xen_guest)
+		xen_pvh_init();
 }
 
 /*
@@ -97,13 +114,17 @@ static void hypervisor_specific_init(void)
  */
 void __init xen_prepare_pvh(void)
 {
+
+	u32 msr = xen_cpuid_base();
+	bool xen_guest = !!msr;
+
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	hypervisor_specific_init();
+	hypervisor_specific_init(xen_guest);
 
-	init_pvh_bootparams();
+	init_pvh_bootparams(xen_guest);
 }
-- 
2.16.1


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

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/Kconfig          | 8 ++++++++
>  arch/x86/kernel/head_64.S | 4 ++--
>  arch/x86/xen/Kconfig      | 3 ++-
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..fa7cd0305125 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,14 @@ config KVM_GUEST
>  	  underlying device model, the host provides the guest with
>  	  timing infrastructure such as time of day, and system time
>  
> +config PVH
> +	bool "Support for running PVH guests"
> +	depends on KVM_GUEST || XEN
> +	def_bool n
> +	---help---
> +	  This option enables the PVH entry point for guest virtual machines
> +	  as specified in the x86/HVM direct boot ABI.
> +
>  config KVM_DEBUG_FS
>  	bool "Enable debug information for KVM Guests in debugfs"
>  	depends on KVM_GUEST && DEBUG_FS
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index 0f545b3cf926..fc9f678c6413 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -41,7 +41,7 @@
>  
>  #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
>  
> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>  PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
>  PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
>  #endif
> @@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
>  
>  	.data
>  
> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>  NEXT_PGD_PAGE(init_top_pgt)
>  	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
>  	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index f605825a04ab..021c8591c3c0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>  	  Enabling this option may incur a significant performance overhead.
>  
>  config XEN_PVH
> -	bool "Support for running as a PVH guest"
> +	bool "Support for running as a Xen PVH guest"
>  	depends on XEN && XEN_PVHVM && ACPI
>  	# Pre-built page tables are not ready to handle 5-level paging.
>  	depends on !X86_5LEVEL

Not specific to this patch, but why is this there? PVH is not using PV so
there should be no problems with 5 level paging.

Juergen, thoughts?

> +	select PVH
>  	def_bool n
> -- 
> 2.16.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/Kconfig          | 8 ++++++++
>  arch/x86/kernel/head_64.S | 4 ++--
>  arch/x86/xen/Kconfig      | 3 ++-
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..fa7cd0305125 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,14 @@ config KVM_GUEST
>  	  underlying device model, the host provides the guest with
>  	  timing infrastructure such as time of day, and system time
>  
> +config PVH
> +	bool "Support for running PVH guests"
> +	depends on KVM_GUEST || XEN
> +	def_bool n
> +	---help---
> +	  This option enables the PVH entry point for guest virtual machines
> +	  as specified in the x86/HVM direct boot ABI.
> +
>  config KVM_DEBUG_FS
>  	bool "Enable debug information for KVM Guests in debugfs"
>  	depends on KVM_GUEST && DEBUG_FS
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index 0f545b3cf926..fc9f678c6413 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -41,7 +41,7 @@
>  
>  #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
>  
> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>  PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
>  PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
>  #endif
> @@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
>  
>  	.data
>  
> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>  NEXT_PGD_PAGE(init_top_pgt)
>  	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
>  	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index f605825a04ab..021c8591c3c0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>  	  Enabling this option may incur a significant performance overhead.
>  
>  config XEN_PVH
> -	bool "Support for running as a PVH guest"
> +	bool "Support for running as a Xen PVH guest"
>  	depends on XEN && XEN_PVHVM && ACPI
>  	# Pre-built page tables are not ready to handle 5-level paging.
>  	depends on !X86_5LEVEL

Not specific to this patch, but why is this there? PVH is not using PV so
there should be no problems with 5 level paging.

Juergen, thoughts?

> +	select PVH
>  	def_bool n
> -- 
> 2.16.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:58AM -0800, Maran Wilson wrote:
> Once hypervisors other than Xen start using the PVH entry point for
> starting VMs, we would like the option of being able to compile PVH entry
> capable kernels without enabling CONFIG_XEN and all the code that comes
> along with that. To allow that, we are moving the PVH code out of Xen and
> into files sitting at a higher level in the tree.
> 
> This patch is not introducing any code or functional changes, just moving
> files from one location to another.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you!
> ---
>  MAINTAINERS                             | 1 +
>  arch/x86/Kbuild                         | 3 +++
>  arch/x86/{xen/xen-pvh.S => pvh-head.S}  | 0
>  arch/x86/{xen/enlighten_pvh.c => pvh.c} | 0
>  arch/x86/xen/Makefile                   | 2 --
>  5 files changed, 4 insertions(+), 2 deletions(-)
>  rename arch/x86/{xen/xen-pvh.S => pvh-head.S} (100%)
>  rename arch/x86/{xen/enlighten_pvh.c => pvh.c} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 93a12af4f180..dc89f3a279bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15210,6 +15210,7 @@ L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
>  S:	Supported
>  F:	arch/x86/xen/
> +F:	arch/x86/*pvh*
>  F:	drivers/*/xen-*front.c
>  F:	drivers/xen/
>  F:	arch/x86/include/asm/xen/
> diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
> index 0038a2d10a7a..a4e5e3d348dc 100644
> --- a/arch/x86/Kbuild
> +++ b/arch/x86/Kbuild
> @@ -7,6 +7,9 @@ obj-$(CONFIG_KVM) += kvm/
>  # Xen paravirtualization support
>  obj-$(CONFIG_XEN) += xen/
>  
> +obj-$(CONFIG_XEN_PVH) += pvh.o
> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
> +
>  # Hyper-V paravirtualization support
>  obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
>  
> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/pvh-head.S
> similarity index 100%
> rename from arch/x86/xen/xen-pvh.S
> rename to arch/x86/pvh-head.S
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/pvh.c
> similarity index 100%
> rename from arch/x86/xen/enlighten_pvh.c
> rename to arch/x86/pvh.c
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index d83cb5478f54..7e8145b33997 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -21,7 +21,6 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
>  obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
>  obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
>  						p2m.o enlighten_pv.o mmu_pv.o
> -obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
> @@ -33,4 +32,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
>  obj-$(CONFIG_XEN_DOM0)		+= vga.o
>  obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
>  obj-$(CONFIG_XEN_EFI)		+= efi.o
> -obj-$(CONFIG_XEN_PVH)	 	+= xen-pvh.o
> -- 
> 2.16.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:58AM -0800, Maran Wilson wrote:
> Once hypervisors other than Xen start using the PVH entry point for
> starting VMs, we would like the option of being able to compile PVH entry
> capable kernels without enabling CONFIG_XEN and all the code that comes
> along with that. To allow that, we are moving the PVH code out of Xen and
> into files sitting at a higher level in the tree.
> 
> This patch is not introducing any code or functional changes, just moving
> files from one location to another.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you!
> ---
>  MAINTAINERS                             | 1 +
>  arch/x86/Kbuild                         | 3 +++
>  arch/x86/{xen/xen-pvh.S => pvh-head.S}  | 0
>  arch/x86/{xen/enlighten_pvh.c => pvh.c} | 0
>  arch/x86/xen/Makefile                   | 2 --
>  5 files changed, 4 insertions(+), 2 deletions(-)
>  rename arch/x86/{xen/xen-pvh.S => pvh-head.S} (100%)
>  rename arch/x86/{xen/enlighten_pvh.c => pvh.c} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 93a12af4f180..dc89f3a279bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15210,6 +15210,7 @@ L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
>  S:	Supported
>  F:	arch/x86/xen/
> +F:	arch/x86/*pvh*
>  F:	drivers/*/xen-*front.c
>  F:	drivers/xen/
>  F:	arch/x86/include/asm/xen/
> diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
> index 0038a2d10a7a..a4e5e3d348dc 100644
> --- a/arch/x86/Kbuild
> +++ b/arch/x86/Kbuild
> @@ -7,6 +7,9 @@ obj-$(CONFIG_KVM) += kvm/
>  # Xen paravirtualization support
>  obj-$(CONFIG_XEN) += xen/
>  
> +obj-$(CONFIG_XEN_PVH) += pvh.o
> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
> +
>  # Hyper-V paravirtualization support
>  obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
>  
> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/pvh-head.S
> similarity index 100%
> rename from arch/x86/xen/xen-pvh.S
> rename to arch/x86/pvh-head.S
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/pvh.c
> similarity index 100%
> rename from arch/x86/xen/enlighten_pvh.c
> rename to arch/x86/pvh.c
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index d83cb5478f54..7e8145b33997 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -21,7 +21,6 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
>  obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
>  obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
>  						p2m.o enlighten_pv.o mmu_pv.o
> -obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
> @@ -33,4 +32,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
>  obj-$(CONFIG_XEN_DOM0)		+= vga.o
>  obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
>  obj-$(CONFIG_XEN_EFI)		+= efi.o
> -obj-$(CONFIG_XEN_PVH)	 	+= xen-pvh.o
> -- 
> 2.16.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:59AM -0800, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> The first step in that direction is to create a new file that will
> eventually hold the Xen specific routines.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/pvh.c               |  1 -
>  arch/x86/xen/Makefile        |  1 +
>  arch/x86/xen/enlighten_pvh.c | 11 +++++++++++
>  3 files changed, 12 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/xen/enlighten_pvh.c
> 
> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
> index 436c4f003e17..b56cb5e7d6ac 100644
> --- a/arch/x86/pvh.c
> +++ b/arch/x86/pvh.c
> @@ -19,7 +19,6 @@
>   * xen_pvh and pvh_bootparams need to live in data segment since they

Perhaps remove 'xen_pvh' from there..
>   * are used after startup_{32|64}, which clear .bss, are invoked.
>   */
> -bool xen_pvh __attribute__((section(".data"))) = 0;
>  struct boot_params pvh_bootparams __attribute__((section(".data")));
>  
>  struct hvm_start_info pvh_start_info;
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 7e8145b33997..ef6481a83768 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -21,6 +21,7 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
>  obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
>  obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
>  						p2m.o enlighten_pv.o mmu_pv.o
> +obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> new file mode 100644
> index 000000000000..4b4e9cc78b8a
> --- /dev/null
> +++ b/arch/x86/xen/enlighten_pvh.c
> @@ -0,0 +1,11 @@
> +#include <linux/types.h>
> +
> +/*
> + * PVH variables.
> + *
> + * The variables xen_pvh and pvh_bootparams need to live in the data segment

And remove 'and pvh_bootparams' here as well?

> + * since they are used after startup_{32|64} is invoked, which will clear the
> + * .bss segment.
> + */
> +bool xen_pvh __attribute__((section(".data"))) = 0;
> +
> -- 
> 2.16.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:59AM -0800, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> The first step in that direction is to create a new file that will
> eventually hold the Xen specific routines.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/pvh.c               |  1 -
>  arch/x86/xen/Makefile        |  1 +
>  arch/x86/xen/enlighten_pvh.c | 11 +++++++++++
>  3 files changed, 12 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/xen/enlighten_pvh.c
> 
> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
> index 436c4f003e17..b56cb5e7d6ac 100644
> --- a/arch/x86/pvh.c
> +++ b/arch/x86/pvh.c
> @@ -19,7 +19,6 @@
>   * xen_pvh and pvh_bootparams need to live in data segment since they

Perhaps remove 'xen_pvh' from there..
>   * are used after startup_{32|64}, which clear .bss, are invoked.
>   */
> -bool xen_pvh __attribute__((section(".data"))) = 0;
>  struct boot_params pvh_bootparams __attribute__((section(".data")));
>  
>  struct hvm_start_info pvh_start_info;
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 7e8145b33997..ef6481a83768 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -21,6 +21,7 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
>  obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
>  obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
>  						p2m.o enlighten_pv.o mmu_pv.o
> +obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> new file mode 100644
> index 000000000000..4b4e9cc78b8a
> --- /dev/null
> +++ b/arch/x86/xen/enlighten_pvh.c
> @@ -0,0 +1,11 @@
> +#include <linux/types.h>
> +
> +/*
> + * PVH variables.
> + *
> + * The variables xen_pvh and pvh_bootparams need to live in the data segment

And remove 'and pvh_bootparams' here as well?

> + * since they are used after startup_{32|64} is invoked, which will clear the
> + * .bss segment.
> + */
> +bool xen_pvh __attribute__((section(".data"))) = 0;
> +
> -- 
> 2.16.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:28:00AM -0800, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you!

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:28:00AM -0800, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you!

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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Paolo Bonzini]

On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
> +obj-$(CONFIG_XEN_PVH) += pvh.o
> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
> +

Probably a better place for these would be
arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
.c or .S files in arch/x86).  Maybe Xen ought to be moved under
arch/x86/platform too.

Paolo

Re: [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Paolo Bonzini]

On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
> +obj-$(CONFIG_XEN_PVH) += pvh.o
> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
> +

Probably a better place for these would be
arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
.c or .S files in arch/x86).  Maybe Xen ought to be moved under
arch/x86/platform too.

Paolo

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

Re: [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Paolo Bonzini]

On 28/02/2018 19:27, Maran Wilson wrote:
> Sorry for the delay between this version and the last -- it was mostly
> due to holidays and everyone being focused on security bug mitigation
> issues. Here are the links to the previous email threads in case it is
> helpful:
> 
> V3: https://lkml.org/lkml/2017/12/12/1230
> V2: https://lkml.org/lkml/2017/12/7/1624
> V1: https://lkml.org/lkml/2017/11/28/1280
> 
> Changes from v3:
> 
>  * Implemented Juergen's suggestion for refactoring and moving the PVH
>    code so that CONFIG_XEN is no longer required for booting KVM guests
>    via the PVH entry point.
>    Functionally, nothing has changed from V3 really, but the patches
>    look completely different now because of all the code movement and
>    refactoring. Some of these patches can be combined, but I've left
>    them very small in some cases to make the refactoring and code
>    movement easier to review.
>    My approach for refactoring has been to create a PVH entry layer that
>    still has understanding and knowledge about Xen vs non-Xen guest types
>    so that it can make run time decisions to handle either case, as
>    opposed to going all the way and re-writing it to be a completely
>    hypervisor agnostic and architecturally pure layer that is separate
>    from guest type details. The latter seemed a bit overkill in this
>    situation. And I've handled the complexity of having to support
>    Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
>    pair of xen specific __weak routines that can be overridden in kernels
>    that support Xen guests. Importantly, the __weak routines are for
>    xen specific code only (not generic "guest type" specific code) so
>    there is no clashing between xen version of the strong routine and,
>    say, a KVM version of the same routine. But I'm sure there are many
>    ways to skin this cat, so I'm open to alternate suggestions if there
>    is a compelling reason for not using __weak in this situation.

As you say there are many ways to achieve this and I think your choice
is fully reasonable (the other alternative that comes to mind is a "Xen
detect" function that returns a struct of function pointers).

Apart from the placement of the files, it looks great.  Thanks!

Paolo

Re: [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Paolo Bonzini]

On 28/02/2018 19:27, Maran Wilson wrote:
> Sorry for the delay between this version and the last -- it was mostly
> due to holidays and everyone being focused on security bug mitigation
> issues. Here are the links to the previous email threads in case it is
> helpful:
> 
> V3: https://lkml.org/lkml/2017/12/12/1230
> V2: https://lkml.org/lkml/2017/12/7/1624
> V1: https://lkml.org/lkml/2017/11/28/1280
> 
> Changes from v3:
> 
>  * Implemented Juergen's suggestion for refactoring and moving the PVH
>    code so that CONFIG_XEN is no longer required for booting KVM guests
>    via the PVH entry point.
>    Functionally, nothing has changed from V3 really, but the patches
>    look completely different now because of all the code movement and
>    refactoring. Some of these patches can be combined, but I've left
>    them very small in some cases to make the refactoring and code
>    movement easier to review.
>    My approach for refactoring has been to create a PVH entry layer that
>    still has understanding and knowledge about Xen vs non-Xen guest types
>    so that it can make run time decisions to handle either case, as
>    opposed to going all the way and re-writing it to be a completely
>    hypervisor agnostic and architecturally pure layer that is separate
>    from guest type details. The latter seemed a bit overkill in this
>    situation. And I've handled the complexity of having to support
>    Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
>    pair of xen specific __weak routines that can be overridden in kernels
>    that support Xen guests. Importantly, the __weak routines are for
>    xen specific code only (not generic "guest type" specific code) so
>    there is no clashing between xen version of the strong routine and,
>    say, a KVM version of the same routine. But I'm sure there are many
>    ways to skin this cat, so I'm open to alternate suggestions if there
>    is a compelling reason for not using __weak in this situation.

As you say there are many ways to achieve this and I think your choice
is fully reasonable (the other alternative that comes to mind is a "Xen
detect" function that returns a struct of function pointers).

Apart from the placement of the files, it looks great.  Thanks!

Paolo

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

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Juergen Gross]

On 28/02/18 22:07, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote:
>> In order to pave the way for hypervisors other then Xen to use the PVH
>> entry point for VMs, we need to factor the PVH entry code into Xen specific
>> and hypervisor agnostic components. The first step in doing that, is to
>> create a new config option for PVH entry that can be enabled
>> independently from CONFIG_XEN.
>>
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> ---
>>  arch/x86/Kconfig          | 8 ++++++++
>>  arch/x86/kernel/head_64.S | 4 ++--
>>  arch/x86/xen/Kconfig      | 3 ++-
>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eb7f43f23521..fa7cd0305125 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -791,6 +791,14 @@ config KVM_GUEST
>>  	  underlying device model, the host provides the guest with
>>  	  timing infrastructure such as time of day, and system time
>>  
>> +config PVH
>> +	bool "Support for running PVH guests"
>> +	depends on KVM_GUEST || XEN
>> +	def_bool n
>> +	---help---
>> +	  This option enables the PVH entry point for guest virtual machines
>> +	  as specified in the x86/HVM direct boot ABI.
>> +
>>  config KVM_DEBUG_FS
>>  	bool "Enable debug information for KVM Guests in debugfs"
>>  	depends on KVM_GUEST && DEBUG_FS
>> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
>> index 0f545b3cf926..fc9f678c6413 100644
>> --- a/arch/x86/kernel/head_64.S
>> +++ b/arch/x86/kernel/head_64.S
>> @@ -41,7 +41,7 @@
>>  
>>  #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
>>  
>> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
>> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>>  PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
>>  PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
>>  #endif
>> @@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
>>  
>>  	.data
>>  
>> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
>> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>>  NEXT_PGD_PAGE(init_top_pgt)
>>  	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
>>  	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index f605825a04ab..021c8591c3c0 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>>  	  Enabling this option may incur a significant performance overhead.
>>  
>>  config XEN_PVH
>> -	bool "Support for running as a PVH guest"
>> +	bool "Support for running as a Xen PVH guest"
>>  	depends on XEN && XEN_PVHVM && ACPI
>>  	# Pre-built page tables are not ready to handle 5-level paging.
>>  	depends on !X86_5LEVEL
> 
> Not specific to this patch, but why is this there? PVH is not using PV so
> there should be no problems with 5 level paging.
> 
> Juergen, thoughts?

This dependency will be removed with Kyrill's series enabling to boot
the same kernel with either 5- or 4-level paging.

Adding 5-level paging support to the PVH boot path could be done later.
OTOH the same could be achieved by using grub2 to boot in PVH mode (with
my grub2 PVH series) as this variant is using the common Linux boot
entry, not the PVH specific one.


Juergen

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Juergen Gross]

On 28/02/18 22:07, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote:
>> In order to pave the way for hypervisors other then Xen to use the PVH
>> entry point for VMs, we need to factor the PVH entry code into Xen specific
>> and hypervisor agnostic components. The first step in doing that, is to
>> create a new config option for PVH entry that can be enabled
>> independently from CONFIG_XEN.
>>
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> ---
>>  arch/x86/Kconfig          | 8 ++++++++
>>  arch/x86/kernel/head_64.S | 4 ++--
>>  arch/x86/xen/Kconfig      | 3 ++-
>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eb7f43f23521..fa7cd0305125 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -791,6 +791,14 @@ config KVM_GUEST
>>  	  underlying device model, the host provides the guest with
>>  	  timing infrastructure such as time of day, and system time
>>  
>> +config PVH
>> +	bool "Support for running PVH guests"
>> +	depends on KVM_GUEST || XEN
>> +	def_bool n
>> +	---help---
>> +	  This option enables the PVH entry point for guest virtual machines
>> +	  as specified in the x86/HVM direct boot ABI.
>> +
>>  config KVM_DEBUG_FS
>>  	bool "Enable debug information for KVM Guests in debugfs"
>>  	depends on KVM_GUEST && DEBUG_FS
>> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
>> index 0f545b3cf926..fc9f678c6413 100644
>> --- a/arch/x86/kernel/head_64.S
>> +++ b/arch/x86/kernel/head_64.S
>> @@ -41,7 +41,7 @@
>>  
>>  #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
>>  
>> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
>> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>>  PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
>>  PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
>>  #endif
>> @@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
>>  
>>  	.data
>>  
>> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
>> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>>  NEXT_PGD_PAGE(init_top_pgt)
>>  	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
>>  	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index f605825a04ab..021c8591c3c0 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>>  	  Enabling this option may incur a significant performance overhead.
>>  
>>  config XEN_PVH
>> -	bool "Support for running as a PVH guest"
>> +	bool "Support for running as a Xen PVH guest"
>>  	depends on XEN && XEN_PVHVM && ACPI
>>  	# Pre-built page tables are not ready to handle 5-level paging.
>>  	depends on !X86_5LEVEL
> 
> Not specific to this patch, but why is this there? PVH is not using PV so
> there should be no problems with 5 level paging.
> 
> Juergen, thoughts?

This dependency will be removed with Kyrill's series enabling to boot
the same kernel with either 5- or 4-level paging.

Adding 5-level paging support to the PVH boot path could be done later.
OTOH the same could be achieved by using grub2 to boot in PVH mode (with
my grub2 PVH series) as this variant is using the common Linux boot
entry, not the PVH specific one.


Juergen

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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Juergen Gross]

On 28/02/18 22:35, Paolo Bonzini wrote:
> On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
>> +obj-$(CONFIG_XEN_PVH) += pvh.o
>> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
>> +
> 
> Probably a better place for these would be
> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
> .c or .S files in arch/x86).

Right.

> Maybe Xen ought to be moved under
> arch/x86/platform too.

And hyperv and kvm, too?

No, I think arch/x86/xen/ is fine.


Juergen

Re: [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Juergen Gross]

On 28/02/18 22:35, Paolo Bonzini wrote:
> On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
>> +obj-$(CONFIG_XEN_PVH) += pvh.o
>> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
>> +
> 
> Probably a better place for these would be
> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
> .c or .S files in arch/x86).

Right.

> Maybe Xen ought to be moved under
> arch/x86/platform too.

And hyperv and kvm, too?

No, I think arch/x86/xen/ is fine.


Juergen

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

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Juergen Gross]

On 28/02/18 19:27, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Juergen Gross]

On 28/02/18 19:27, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

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

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

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

Re: [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> The original design for PVH entry in Xen guests relies on being able to
> obtain the memory map from the hypervisor using a hypercall. When we
> extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
> a new mechanism will be added that allows the guest to get the memory
> map without needing to use hypercalls.
> 
> For Xen guests, the hypercall approach will still be supported. In
> preparation for adding support for other hypervisors, we can move the
> code that uses hypercalls into the Xen specific file. This will allow us
> to compile kernels in the future without CONFIG_XEN that are still capable
> of being booted as a Qemu/KVM guest via the PVH entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

Re: [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> The original design for PVH entry in Xen guests relies on being able to
> obtain the memory map from the hypervisor using a hypercall. When we
> extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
> a new mechanism will be added that allows the guest to get the memory
> map without needing to use hypercalls.
> 
> For Xen guests, the hypercall approach will still be supported. In
> preparation for adding support for other hypervisors, we can move the
> code that uses hypercalls into the Xen specific file. This will allow us
> to compile kernels in the future without CONFIG_XEN that are still capable
> of being booted as a Qemu/KVM guest via the PVH entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

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

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to share the same entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

I'm fine with this, but we need this change being accepted by the Xen
community first. So an Ack from Jan or Andrew is required as the same
change should be done on Xen side.

Juergen

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to share the same entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

I'm fine with this, but we need this change being accepted by the Xen
community first. So an Ack from Jan or Andrew is required as the same
change should be done on Xen side.

Juergen

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

Re: [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without the need to run firmware.
> 
> There already exists an ABI to allow this for Xen PVH guests and the ABI
> is supported by Linux and FreeBSD:
> 
>    https://xenbits.xen.org/docs/unstable/misc/pvh.html
> 
> This patch enables Qemu to use that same entry point for booting KVM
> guests.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

Re: [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without the need to run firmware.
> 
> There already exists an ABI to allow this for Xen PVH guests and the ABI
> is supported by Linux and FreeBSD:
> 
>    https://xenbits.xen.org/docs/unstable/misc/pvh.html
> 
> This patch enables Qemu to use that same entry point for booting KVM
> guests.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

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

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Jan Beulich]

>>>> Juergen Gross <jgross@suse.com> 03/01/18 8:29 AM >>>
>On 28/02/18 19:28, Maran Wilson wrote:
>> The start info structure that is defined as part of the x86/HVM direct boot
>> ABI and used for starting Xen PVH guests would be more versatile if it also
>> included a way to pass information about the memory map to the guest. This
>> would allow KVM guests to share the same entry point.
>> 
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>
>I'm fine with this, but we need this change being accepted by the Xen
>community first. So an Ack from Jan or Andrew is required as the same
>change should be done on Xen side.

And for an ack to be given I continue to demand that a patch be sent against
the Xen tree. That said, the change looks fine to me now (as indicated before).

Jan

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Jan Beulich]

>>>> Juergen Gross <jgross@suse.com> 03/01/18 8:29 AM >>>
>On 28/02/18 19:28, Maran Wilson wrote:
>> The start info structure that is defined as part of the x86/HVM direct boot
>> ABI and used for starting Xen PVH guests would be more versatile if it also
>> included a way to pass information about the memory map to the guest. This
>> would allow KVM guests to share the same entry point.
>> 
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>
>I'm fine with this, but we need this change being accepted by the Xen
>community first. So an Ack from Jan or Andrew is required as the same
>change should be done on Xen side.

And for an ack to be given I continue to demand that a patch be sent against
the Xen tree. That said, the change looks fine to me now (as indicated before).

Jan

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Jan Beulich]

>>>> Juergen Gross <jgross@suse.com> 03/01/18 8:29 AM >>>
>On 28/02/18 19:28, Maran Wilson wrote:
>> The start info structure that is defined as part of the x86/HVM direct boot
>> ABI and used for starting Xen PVH guests would be more versatile if it also
>> included a way to pass information about the memory map to the guest. This
>> would allow KVM guests to share the same entry point.
>> 
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>
>I'm fine with this, but we need this change being accepted by the Xen
>community first. So an Ack from Jan or Andrew is required as the same
>change should be done on Xen side.

And for an ack to be given I continue to demand that a patch be sent against
the Xen tree. That said, the change looks fine to me now (as indicated before).

Jan


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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Paolo Bonzini]

On 01/03/2018 07:11, Juergen Gross wrote:
>> Probably a better place for these would be
>> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
>> .c or .S files in arch/x86).
> Right.
> 
>> Maybe Xen ought to be moved under
>> arch/x86/platform too.
> And hyperv and kvm, too?

Actually yes, though for kvm I'd move the files in arch/x86/kernel
(arch/x86/kvm is the hypervisor itself, not the "platform").

> No, I think arch/x86/xen/ is fine.

np, it was just a (somewhat crazy) suggestion. :)

Paolo

Re: [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Paolo Bonzini]

On 01/03/2018 07:11, Juergen Gross wrote:
>> Probably a better place for these would be
>> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
>> .c or .S files in arch/x86).
> Right.
> 
>> Maybe Xen ought to be moved under
>> arch/x86/platform too.
> And hyperv and kvm, too?

Actually yes, though for kvm I'd move the files in arch/x86/kernel
(arch/x86/kvm is the hypervisor itself, not the "platform").

> No, I think arch/x86/xen/ is fine.

np, it was just a (somewhat crazy) suggestion. :)

Paolo

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

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Boris Ostrovsky]

On 02/28/2018 01:27 PM, Maran Wilson wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..fa7cd0305125 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,14 @@ config KVM_GUEST
>  	  underlying device model, the host provides the guest with
>  	  timing infrastructure such as time of day, and system time
>  
> +config PVH
> +	bool "Support for running PVH guests"
> +	depends on KVM_GUEST || XEN


Not sure about XEN part. PVH is selected by XEN_PVH for Xen.

What about introducing KVM_GUEST_PVH that will select PVH and then drop
dependency here?


-boris

> +	def_bool n
> +	---help---
> +	  This option enables the PVH entry point for guest virtual machines
> +	  as specified in the x86/HVM direct boot ABI.
> +
>  


> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index f605825a04ab..021c8591c3c0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>  	  Enabling this option may incur a significant performance overhead.
>  
>  config XEN_PVH
> -	bool "Support for running as a PVH guest"
> +	bool "Support for running as a Xen PVH guest"
>  	depends on XEN && XEN_PVHVM && ACPI
>  	# Pre-built page tables are not ready to handle 5-level paging.
>  	depends on !X86_5LEVEL
> +	select PVH
>  	def_bool n

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Boris Ostrovsky]

On 02/28/2018 01:27 PM, Maran Wilson wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..fa7cd0305125 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,14 @@ config KVM_GUEST
>  	  underlying device model, the host provides the guest with
>  	  timing infrastructure such as time of day, and system time
>  
> +config PVH
> +	bool "Support for running PVH guests"
> +	depends on KVM_GUEST || XEN


Not sure about XEN part. PVH is selected by XEN_PVH for Xen.

What about introducing KVM_GUEST_PVH that will select PVH and then drop
dependency here?


-boris

> +	def_bool n
> +	---help---
> +	  This option enables the PVH entry point for guest virtual machines
> +	  as specified in the x86/HVM direct boot ABI.
> +
>  


> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index f605825a04ab..021c8591c3c0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>  	  Enabling this option may incur a significant performance overhead.
>  
>  config XEN_PVH
> -	bool "Support for running as a PVH guest"
> +	bool "Support for running as a Xen PVH guest"
>  	depends on XEN && XEN_PVHVM && ACPI
>  	# Pre-built page tables are not ready to handle 5-level paging.
>  	depends on !X86_5LEVEL
> +	select PVH
>  	def_bool n


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

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Paolo Bonzini]

On 01/03/2018 16:02, Boris Ostrovsky wrote:
> On 02/28/2018 01:27 PM, Maran Wilson wrote:
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eb7f43f23521..fa7cd0305125 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -791,6 +791,14 @@ config KVM_GUEST
>>  	  underlying device model, the host provides the guest with
>>  	  timing infrastructure such as time of day, and system time
>>  
>> +config PVH
>> +	bool "Support for running PVH guests"
>> +	depends on KVM_GUEST || XEN
> 
> 
> Not sure about XEN part. PVH is selected by XEN_PVH for Xen.
> 
> What about introducing KVM_GUEST_PVH that will select PVH and then drop
> dependency here?

That is, "config KVM_GUEST_PVH" "depends on KVM_GUEST" "select PVH".
Sounds good to me.

Paolo

> 
> -boris
> 
>> +	def_bool n
>> +	---help---
>> +	  This option enables the PVH entry point for guest virtual machines
>> +	  as specified in the x86/HVM direct boot ABI.
>> +
>>  
> 
> 
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index f605825a04ab..021c8591c3c0 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>>  	  Enabling this option may incur a significant performance overhead.
>>  
>>  config XEN_PVH
>> -	bool "Support for running as a PVH guest"
>> +	bool "Support for running as a Xen PVH guest"
>>  	depends on XEN && XEN_PVHVM && ACPI
>>  	# Pre-built page tables are not ready to handle 5-level paging.
>>  	depends on !X86_5LEVEL
>> +	select PVH
>>  	def_bool n
> 

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Paolo Bonzini]

On 01/03/2018 16:02, Boris Ostrovsky wrote:
> On 02/28/2018 01:27 PM, Maran Wilson wrote:
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eb7f43f23521..fa7cd0305125 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -791,6 +791,14 @@ config KVM_GUEST
>>  	  underlying device model, the host provides the guest with
>>  	  timing infrastructure such as time of day, and system time
>>  
>> +config PVH
>> +	bool "Support for running PVH guests"
>> +	depends on KVM_GUEST || XEN
> 
> 
> Not sure about XEN part. PVH is selected by XEN_PVH for Xen.
> 
> What about introducing KVM_GUEST_PVH that will select PVH and then drop
> dependency here?

That is, "config KVM_GUEST_PVH" "depends on KVM_GUEST" "select PVH".
Sounds good to me.

Paolo

> 
> -boris
> 
>> +	def_bool n
>> +	---help---
>> +	  This option enables the PVH entry point for guest virtual machines
>> +	  as specified in the x86/HVM direct boot ABI.
>> +
>>  
> 
> 
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index f605825a04ab..021c8591c3c0 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>>  	  Enabling this option may incur a significant performance overhead.
>>  
>>  config XEN_PVH
>> -	bool "Support for running as a PVH guest"
>> +	bool "Support for running as a Xen PVH guest"
>>  	depends on XEN && XEN_PVHVM && ACPI
>>  	# Pre-built page tables are not ready to handle 5-level paging.
>>  	depends on !X86_5LEVEL
>> +	select PVH
>>  	def_bool n
> 


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

Re: [Xen-devel] [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:28:02AM -0800, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to share the same entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  include/xen/interface/hvm/start_info.h | 50 +++++++++++++++++++++++++++++++++-
>  1 file changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/include/xen/interface/hvm/start_info.h b/include/xen/interface/hvm/start_info.h
> index 648415976ead..80cfbd35c1af 100644
> --- a/include/xen/interface/hvm/start_info.h
> +++ b/include/xen/interface/hvm/start_info.h
> @@ -33,7 +33,7 @@
>   *    | magic          | Contains the magic value XEN_HVM_START_MAGIC_VALUE
>   *    |                | ("xEn3" with the 0x80 bit of the "E" set).
>   *  4 +----------------+
> - *    | version        | Version of this structure. Current version is 0. New
> + *    | version        | Version of this structure. Current version is 1. New

Have you checked if there are any OSes that end up checking this value at all?

Perhaps also expand the comment to say that for PV guests only 0 is allowed.
For PVH 0 or 1 is allowed ?

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:28:02AM -0800, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to share the same entry point.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  include/xen/interface/hvm/start_info.h | 50 +++++++++++++++++++++++++++++++++-
>  1 file changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/include/xen/interface/hvm/start_info.h b/include/xen/interface/hvm/start_info.h
> index 648415976ead..80cfbd35c1af 100644
> --- a/include/xen/interface/hvm/start_info.h
> +++ b/include/xen/interface/hvm/start_info.h
> @@ -33,7 +33,7 @@
>   *    | magic          | Contains the magic value XEN_HVM_START_MAGIC_VALUE
>   *    |                | ("xEn3" with the 0x80 bit of the "E" set).
>   *  4 +----------------+
> - *    | version        | Version of this structure. Current version is 0. New
> + *    | version        | Version of this structure. Current version is 1. New

Have you checked if there are any OSes that end up checking this value at all?

Perhaps also expand the comment to say that for PV guests only 0 is allowed.
For PVH 0 or 1 is allowed ?

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

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Boris Ostrovsky]

On 02/28/2018 01:28 PM, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
>
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
>
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/pvh.c               | 28 ++++++++++++++++++++--------
>  arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++-
>  2 files changed, 37 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
> index b56cb5e7d6ac..2d7a7f4958cb 100644
> --- a/arch/x86/pvh.c
> +++ b/arch/x86/pvh.c
> @@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
>  	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
>  }
>  
> +/*
> + * If we are trying to boot a Xen PVH guest, it is expected that the kernel
> + * will have been configured to provide the required override for this routine.
> + */
> +void __init __weak xen_pvh_init(void)
> +{
> +	xen_raw_printk("Error: Missing xen PVH initialization\n");

I think this should be printk (or, more precisely, this should not be
xen_raw_printk()): we are here because we are *not* a Xen guest and so
Xen-specific printk will not work. (and the same is true for the next
patch where weak mem_map_via_hcall() is added).

-boris


> +	BUG();
> +}
>

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Boris Ostrovsky]

On 02/28/2018 01:28 PM, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
>
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
>
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/pvh.c               | 28 ++++++++++++++++++++--------
>  arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++-
>  2 files changed, 37 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
> index b56cb5e7d6ac..2d7a7f4958cb 100644
> --- a/arch/x86/pvh.c
> +++ b/arch/x86/pvh.c
> @@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
>  	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
>  }
>  
> +/*
> + * If we are trying to boot a Xen PVH guest, it is expected that the kernel
> + * will have been configured to provide the required override for this routine.
> + */
> +void __init __weak xen_pvh_init(void)
> +{
> +	xen_raw_printk("Error: Missing xen PVH initialization\n");

I think this should be printk (or, more precisely, this should not be
xen_raw_printk()): we are here because we are *not* a Xen guest and so
Xen-specific printk will not work. (and the same is true for the next
patch where weak mem_map_via_hcall() is added).

-boris


> +	BUG();
> +}
>


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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Boris Ostrovsky]

On 03/01/2018 03:46 AM, Paolo Bonzini wrote:
> On 01/03/2018 07:11, Juergen Gross wrote:
>>> Probably a better place for these would be
>>> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
>>> .c or .S files in arch/x86).
>> Right.
>>
>>> Maybe Xen ought to be moved under
>>> arch/x86/platform too.
>> And hyperv and kvm, too?


I was actually thinking about having arch/x86/virt where xen, kvm,
hyperv etc should go. Not as part of this series, obviously.

-boris


> Actually yes, though for kvm I'd move the files in arch/x86/kernel
> (arch/x86/kvm is the hypervisor itself, not the "platform").
>
>> No, I think arch/x86/xen/ is fine.
> np, it was just a (somewhat crazy) suggestion. :)
>
> Paolo

Re: [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Boris Ostrovsky]

On 03/01/2018 03:46 AM, Paolo Bonzini wrote:
> On 01/03/2018 07:11, Juergen Gross wrote:
>>> Probably a better place for these would be
>>> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
>>> .c or .S files in arch/x86).
>> Right.
>>
>>> Maybe Xen ought to be moved under
>>> arch/x86/platform too.
>> And hyperv and kvm, too?


I was actually thinking about having arch/x86/virt where xen, kvm,
hyperv etc should go. Not as part of this series, obviously.

-boris


> Actually yes, though for kvm I'd move the files in arch/x86/kernel
> (arch/x86/kvm is the hypervisor itself, not the "platform").
>
>> No, I think arch/x86/xen/ is fine.
> np, it was just a (somewhat crazy) suggestion. :)
>
> Paolo


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

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

On 2/28/2018 11:41 PM, Jan Beulich wrote:
>>>>> Juergen Gross <jgross@suse.com> 03/01/18 8:29 AM >>>
>> On 28/02/18 19:28, Maran Wilson wrote:
>>> The start info structure that is defined as part of the x86/HVM direct boot
>>> ABI and used for starting Xen PVH guests would be more versatile if it also
>>> included a way to pass information about the memory map to the guest. This
>>> would allow KVM guests to share the same entry point.
>>>
>>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> I'm fine with this, but we need this change being accepted by the Xen
>> community first. So an Ack from Jan or Andrew is required as the same
>> change should be done on Xen side.
> And for an ack to be given I continue to demand that a patch be sent against
> the Xen tree. That said, the change looks fine to me now (as indicated before).

Yes, I plan to send that out against the Xen tree shortly.

Thanks,
-Maran

> Jan
>

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

On 2/28/2018 11:41 PM, Jan Beulich wrote:
>>>>> Juergen Gross <jgross@suse.com> 03/01/18 8:29 AM >>>
>> On 28/02/18 19:28, Maran Wilson wrote:
>>> The start info structure that is defined as part of the x86/HVM direct boot
>>> ABI and used for starting Xen PVH guests would be more versatile if it also
>>> included a way to pass information about the memory map to the guest. This
>>> would allow KVM guests to share the same entry point.
>>>
>>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> I'm fine with this, but we need this change being accepted by the Xen
>> community first. So an Ack from Jan or Andrew is required as the same
>> change should be done on Xen side.
> And for an ack to be given I continue to demand that a patch be sent against
> the Xen tree. That said, the change looks fine to me now (as indicated before).

Yes, I plan to send that out against the Xen tree shortly.

Thanks,
-Maran

> Jan
>


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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

On 2/28/2018 1:35 PM, Paolo Bonzini wrote:
> On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
>> +obj-$(CONFIG_XEN_PVH) += pvh.o
>> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
>> +
> Probably a better place for these would be
> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
> .c or .S files in arch/x86).

Sounds good. Will make that change.

Thanks,
-Maran

> Maybe Xen ought to be moved under
> arch/x86/platform too.
>
> Paolo

Re: [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

On 2/28/2018 1:35 PM, Paolo Bonzini wrote:
> On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
>> +obj-$(CONFIG_XEN_PVH) += pvh.o
>> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
>> +
> Probably a better place for these would be
> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
> .c or .S files in arch/x86).

Sounds good. Will make that change.

Thanks,
-Maran

> Maybe Xen ought to be moved under
> arch/x86/platform too.
>
> Paolo


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

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

On 3/1/2018 7:17 AM, Paolo Bonzini wrote:
> On 01/03/2018 16:02, Boris Ostrovsky wrote:
>> On 02/28/2018 01:27 PM, Maran Wilson wrote:
>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>> index eb7f43f23521..fa7cd0305125 100644
>>> --- a/arch/x86/Kconfig
>>> +++ b/arch/x86/Kconfig
>>> @@ -791,6 +791,14 @@ config KVM_GUEST
>>>   	  underlying device model, the host provides the guest with
>>>   	  timing infrastructure such as time of day, and system time
>>>   
>>> +config PVH
>>> +	bool "Support for running PVH guests"
>>> +	depends on KVM_GUEST || XEN
>>
>> Not sure about XEN part. PVH is selected by XEN_PVH for Xen.
>>
>> What about introducing KVM_GUEST_PVH that will select PVH and then drop
>> dependency here?
> That is, "config KVM_GUEST_PVH" "depends on KVM_GUEST" "select PVH".
> Sounds good to me.

OK, will do.

Thanks,
-Maran

> Paolo
>
>> -boris
>>
>>> +	def_bool n
>>> +	---help---
>>> +	  This option enables the PVH entry point for guest virtual machines
>>> +	  as specified in the x86/HVM direct boot ABI.
>>> +
>>>   
>>
>>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>>> index f605825a04ab..021c8591c3c0 100644
>>> --- a/arch/x86/xen/Kconfig
>>> +++ b/arch/x86/xen/Kconfig
>>> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>>>   	  Enabling this option may incur a significant performance overhead.
>>>   
>>>   config XEN_PVH
>>> -	bool "Support for running as a PVH guest"
>>> +	bool "Support for running as a Xen PVH guest"
>>>   	depends on XEN && XEN_PVHVM && ACPI
>>>   	# Pre-built page tables are not ready to handle 5-level paging.
>>>   	depends on !X86_5LEVEL
>>> +	select PVH
>>>   	def_bool n

Re: [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

On 3/1/2018 7:17 AM, Paolo Bonzini wrote:
> On 01/03/2018 16:02, Boris Ostrovsky wrote:
>> On 02/28/2018 01:27 PM, Maran Wilson wrote:
>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>> index eb7f43f23521..fa7cd0305125 100644
>>> --- a/arch/x86/Kconfig
>>> +++ b/arch/x86/Kconfig
>>> @@ -791,6 +791,14 @@ config KVM_GUEST
>>>   	  underlying device model, the host provides the guest with
>>>   	  timing infrastructure such as time of day, and system time
>>>   
>>> +config PVH
>>> +	bool "Support for running PVH guests"
>>> +	depends on KVM_GUEST || XEN
>>
>> Not sure about XEN part. PVH is selected by XEN_PVH for Xen.
>>
>> What about introducing KVM_GUEST_PVH that will select PVH and then drop
>> dependency here?
> That is, "config KVM_GUEST_PVH" "depends on KVM_GUEST" "select PVH".
> Sounds good to me.

OK, will do.

Thanks,
-Maran

> Paolo
>
>> -boris
>>
>>> +	def_bool n
>>> +	---help---
>>> +	  This option enables the PVH entry point for guest virtual machines
>>> +	  as specified in the x86/HVM direct boot ABI.
>>> +
>>>   
>>
>>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>>> index f605825a04ab..021c8591c3c0 100644
>>> --- a/arch/x86/xen/Kconfig
>>> +++ b/arch/x86/xen/Kconfig
>>> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>>>   	  Enabling this option may incur a significant performance overhead.
>>>   
>>>   config XEN_PVH
>>> -	bool "Support for running as a PVH guest"
>>> +	bool "Support for running as a Xen PVH guest"
>>>   	depends on XEN && XEN_PVHVM && ACPI
>>>   	# Pre-built page tables are not ready to handle 5-level paging.
>>>   	depends on !X86_5LEVEL
>>> +	select PVH
>>>   	def_bool n


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

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Maran Wilson]

On 3/1/2018 8:05 AM, Boris Ostrovsky wrote:
> On 02/28/2018 01:28 PM, Maran Wilson wrote:
>> We need to refactor PVH entry code so that support for other hypervisors
>> like Qemu/KVM can be added more easily.
>>
>> This patch moves the small block of code used for initializing Xen PVH
>> virtual machines into the Xen specific file. This initialization is not
>> going to be needed for Qemu/KVM guests. Moving it out of the common file
>> is going to allow us to compile kernels in the future without CONFIG_XEN
>> that are still capable of being booted as a Qemu/KVM guest via the PVH
>> entry point.
>>
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> ---
>>   arch/x86/pvh.c               | 28 ++++++++++++++++++++--------
>>   arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++-
>>   2 files changed, 37 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
>> index b56cb5e7d6ac..2d7a7f4958cb 100644
>> --- a/arch/x86/pvh.c
>> +++ b/arch/x86/pvh.c
>> @@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
>>   	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
>>   }
>>   
>> +/*
>> + * If we are trying to boot a Xen PVH guest, it is expected that the kernel
>> + * will have been configured to provide the required override for this routine.
>> + */
>> +void __init __weak xen_pvh_init(void)
>> +{
>> +	xen_raw_printk("Error: Missing xen PVH initialization\n");
> I think this should be printk (or, more precisely, this should not be
> xen_raw_printk()): we are here because we are *not* a Xen guest and so
> Xen-specific printk will not work. (and the same is true for the next
> patch where weak mem_map_via_hcall() is added).

Actually I left that xen_raw_printk() statement in on purpose. It's also 
possible that some future developer accidentally drops or hides the 
strong version of the routine even when CONFIG_XEN (and CONFIG_HVC_XEN) 
is enabled. In that situation, this error message might prove helpful in 
quickly identifying the problem when he or she attempts to boot a Xen guest.

And in situations where CONFIG_XEN is disabled or someone is booting a 
non xen guest, the statement simply becomes a nop, so no harm is done. 
And also, I believe this code is far too early for normal printk() 
statements to work so switching to that won't buy us anything.

Thanks,
-Maran

> -boris
>
>
>> +	BUG();
>> +}
>>

Re: [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Maran Wilson]

On 3/1/2018 8:05 AM, Boris Ostrovsky wrote:
> On 02/28/2018 01:28 PM, Maran Wilson wrote:
>> We need to refactor PVH entry code so that support for other hypervisors
>> like Qemu/KVM can be added more easily.
>>
>> This patch moves the small block of code used for initializing Xen PVH
>> virtual machines into the Xen specific file. This initialization is not
>> going to be needed for Qemu/KVM guests. Moving it out of the common file
>> is going to allow us to compile kernels in the future without CONFIG_XEN
>> that are still capable of being booted as a Qemu/KVM guest via the PVH
>> entry point.
>>
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> ---
>>   arch/x86/pvh.c               | 28 ++++++++++++++++++++--------
>>   arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++-
>>   2 files changed, 37 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
>> index b56cb5e7d6ac..2d7a7f4958cb 100644
>> --- a/arch/x86/pvh.c
>> +++ b/arch/x86/pvh.c
>> @@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
>>   	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
>>   }
>>   
>> +/*
>> + * If we are trying to boot a Xen PVH guest, it is expected that the kernel
>> + * will have been configured to provide the required override for this routine.
>> + */
>> +void __init __weak xen_pvh_init(void)
>> +{
>> +	xen_raw_printk("Error: Missing xen PVH initialization\n");
> I think this should be printk (or, more precisely, this should not be
> xen_raw_printk()): we are here because we are *not* a Xen guest and so
> Xen-specific printk will not work. (and the same is true for the next
> patch where weak mem_map_via_hcall() is added).

Actually I left that xen_raw_printk() statement in on purpose. It's also 
possible that some future developer accidentally drops or hides the 
strong version of the routine even when CONFIG_XEN (and CONFIG_HVC_XEN) 
is enabled. In that situation, this error message might prove helpful in 
quickly identifying the problem when he or she attempts to boot a Xen guest.

And in situations where CONFIG_XEN is disabled or someone is booting a 
non xen guest, the statement simply becomes a nop, so no harm is done. 
And also, I believe this code is far too early for normal printk() 
statements to work so switching to that won't buy us anything.

Thanks,
-Maran

> -boris
>
>
>> +	BUG();
>> +}
>>


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

[PATCH v5 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch series would enable Qemu to use that same entry point for
booting KVM guests.

Note: I've withheld Juergen's earlier "Reviewed-by" tags from patches
1 and 7 since there were minor changes (mostly just addition of
CONFIG_KVM_GUEST_PVH as requested) that came afterwards.

Changes from v4:

 * Changed subject prefix from RFC to PATCH
 * Added CONFIG_KVM_GUEST_PVH as suggested
 * Relocated the PVH common files to
   arch/x86/platform/pvh/{enlighten.c,head.S}
 * Realized I also needed to move the objtool override for those files
 * Updated a few code comments per reviewer feedback
 * Sent out a patch of the hvm_start_info struct changes against the Xen
   tree since that is the canonical copy of the header. Discussions on
   that thread have resulted in some (non-functional) updates to
   start_info.h (patch 6/7) and those changes are reflected here as well
   in order to keep the files in sync. The header file has since been
   ack'ed for the Xen tree by Jan Beulich.
https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg02333.html

Changes from v3:

 * Implemented Juergen's suggestion for refactoring and moving the PVH
   code so that CONFIG_XEN is no longer required for booting KVM guests
   via the PVH entry point.
   Functionally, nothing has changed from V3 really, but the patches
   look completely different now because of all the code movement and
   refactoring. Some of these patches can be combined, but I've left
   them very small in some cases to make the refactoring and code
   movement easier to review.
   My approach for refactoring has been to create a PVH entry layer that
   still has understanding and knowledge about Xen vs non-Xen guest types
   so that it can make run time decisions to handle either case, as
   opposed to going all the way and re-writing it to be a completely
   hypervisor agnostic and architecturally pure layer that is separate
   from guest type details. The latter seemed a bit overkill in this
   situation. And I've handled the complexity of having to support
   Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
   pair of xen specific __weak routines that can be overridden in kernels
   that support Xen guests. Importantly, the __weak routines are for
   xen specific code only (not generic "guest type" specific code) so
   there is no clashing between xen version of the strong routine and,
   say, a KVM version of the same routine. But I'm sure there are many
   ways to skin this cat, so I'm open to alternate suggestions if there
   is a compelling reason for not using __weak in this situation.

Changes from v2:

 * All structures (including memory map table entries) are padded and
   aligned to an 8 byte boundary.

 * Removed the "packed" attributes and made changes to comments as
   suggested by Jan.

Changes from v1:

 * Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the
   e820 map instead of using the second module entry to pass the table.

 * Cleaned things up a bit to reduce the number of xen vs non-xen special
   cases.


Maran Wilson (7):
  xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH
  xen/pvh: Move PVH entry code out of Xen specific tree
  xen/pvh: Create a new file for Xen specific PVH code
  xen/pvh: Move Xen specific PVH VM initialization out of common file
  xen/pvh: Move Xen code for getting mem map via hcall out of common
    file
  xen/pvh: Add memory map pointer to hvm_start_info struct
  KVM: x86: Allow Qemu/KVM to use PVH entry point

 MAINTAINERS                                     |   1 +
 arch/x86/Kbuild                                 |   2 +
 arch/x86/Kconfig                                |  15 +++
 arch/x86/kernel/head_64.S                       |   4 +-
 arch/x86/platform/pvh/Makefile                  |   5 +
 arch/x86/platform/pvh/enlighten.c               | 130 ++++++++++++++++++++++++
 arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} |   0
 arch/x86/xen/Kconfig                            |   3 +-
 arch/x86/xen/Makefile                           |   2 -
 arch/x86/xen/enlighten_pvh.c                    |  86 ++++------------
 include/xen/interface/hvm/start_info.h          |  65 +++++++++++-
 11 files changed, 238 insertions(+), 75 deletions(-)
 create mode 100644 arch/x86/platform/pvh/Makefile
 create mode 100644 arch/x86/platform/pvh/enlighten.c
 rename arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} (100%)

-- 
2.16.1

[PATCH v5 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch series would enable Qemu to use that same entry point for
booting KVM guests.

Note: I've withheld Juergen's earlier "Reviewed-by" tags from patches
1 and 7 since there were minor changes (mostly just addition of
CONFIG_KVM_GUEST_PVH as requested) that came afterwards.

Changes from v4:

 * Changed subject prefix from RFC to PATCH
 * Added CONFIG_KVM_GUEST_PVH as suggested
 * Relocated the PVH common files to
   arch/x86/platform/pvh/{enlighten.c,head.S}
 * Realized I also needed to move the objtool override for those files
 * Updated a few code comments per reviewer feedback
 * Sent out a patch of the hvm_start_info struct changes against the Xen
   tree since that is the canonical copy of the header. Discussions on
   that thread have resulted in some (non-functional) updates to
   start_info.h (patch 6/7) and those changes are reflected here as well
   in order to keep the files in sync. The header file has since been
   ack'ed for the Xen tree by Jan Beulich.
https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg02333.html

Changes from v3:

 * Implemented Juergen's suggestion for refactoring and moving the PVH
   code so that CONFIG_XEN is no longer required for booting KVM guests
   via the PVH entry point.
   Functionally, nothing has changed from V3 really, but the patches
   look completely different now because of all the code movement and
   refactoring. Some of these patches can be combined, but I've left
   them very small in some cases to make the refactoring and code
   movement easier to review.
   My approach for refactoring has been to create a PVH entry layer that
   still has understanding and knowledge about Xen vs non-Xen guest types
   so that it can make run time decisions to handle either case, as
   opposed to going all the way and re-writing it to be a completely
   hypervisor agnostic and architecturally pure layer that is separate
   from guest type details. The latter seemed a bit overkill in this
   situation. And I've handled the complexity of having to support
   Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
   pair of xen specific __weak routines that can be overridden in kernels
   that support Xen guests. Importantly, the __weak routines are for
   xen specific code only (not generic "guest type" specific code) so
   there is no clashing between xen version of the strong routine and,
   say, a KVM version of the same routine. But I'm sure there are many
   ways to skin this cat, so I'm open to alternate suggestions if there
   is a compelling reason for not using __weak in this situation.

Changes from v2:

 * All structures (including memory map table entries) are padded and
   aligned to an 8 byte boundary.

 * Removed the "packed" attributes and made changes to comments as
   suggested by Jan.

Changes from v1:

 * Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the
   e820 map instead of using the second module entry to pass the table.

 * Cleaned things up a bit to reduce the number of xen vs non-xen special
   cases.


Maran Wilson (7):
  xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH
  xen/pvh: Move PVH entry code out of Xen specific tree
  xen/pvh: Create a new file for Xen specific PVH code
  xen/pvh: Move Xen specific PVH VM initialization out of common file
  xen/pvh: Move Xen code for getting mem map via hcall out of common
    file
  xen/pvh: Add memory map pointer to hvm_start_info struct
  KVM: x86: Allow Qemu/KVM to use PVH entry point

 MAINTAINERS                                     |   1 +
 arch/x86/Kbuild                                 |   2 +
 arch/x86/Kconfig                                |  15 +++
 arch/x86/kernel/head_64.S                       |   4 +-
 arch/x86/platform/pvh/Makefile                  |   5 +
 arch/x86/platform/pvh/enlighten.c               | 130 ++++++++++++++++++++++++
 arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} |   0
 arch/x86/xen/Kconfig                            |   3 +-
 arch/x86/xen/Makefile                           |   2 -
 arch/x86/xen/enlighten_pvh.c                    |  86 ++++------------
 include/xen/interface/hvm/start_info.h          |  65 +++++++++++-
 11 files changed, 238 insertions(+), 75 deletions(-)
 create mode 100644 arch/x86/platform/pvh/Makefile
 create mode 100644 arch/x86/platform/pvh/enlighten.c
 rename arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} (100%)

-- 
2.16.1


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

[PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

In order to pave the way for hypervisors other then Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from CONFIG_XEN.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/Kconfig          | 7 +++++++
 arch/x86/kernel/head_64.S | 4 ++--
 arch/x86/xen/Kconfig      | 3 ++-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..58831320b5d2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,13 @@ config KVM_GUEST
 	  underlying device model, the host provides the guest with
 	  timing infrastructure such as time of day, and system time
 
+config PVH
+	bool "Support for running PVH guests"
+	def_bool n
+	---help---
+	  This option enables the PVH entry point for guest virtual machines
+	  as specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
 	bool "Enable debug information for KVM Guests in debugfs"
 	depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 0f545b3cf926..fc9f678c6413 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -41,7 +41,7 @@
 
 #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
 PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
 #endif
@@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
 
 	.data
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 NEXT_PGD_PAGE(init_top_pgt)
 	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
 	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index f605825a04ab..021c8591c3c0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -77,8 +77,9 @@ config XEN_DEBUG_FS
 	  Enabling this option may incur a significant performance overhead.
 
 config XEN_PVH
-	bool "Support for running as a PVH guest"
+	bool "Support for running as a Xen PVH guest"
 	depends on XEN && XEN_PVHVM && ACPI
 	# Pre-built page tables are not ready to handle 5-level paging.
 	depends on !X86_5LEVEL
+	select PVH
 	def_bool n
-- 
2.16.1

[PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

In order to pave the way for hypervisors other then Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from CONFIG_XEN.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/Kconfig          | 7 +++++++
 arch/x86/kernel/head_64.S | 4 ++--
 arch/x86/xen/Kconfig      | 3 ++-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..58831320b5d2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,13 @@ config KVM_GUEST
 	  underlying device model, the host provides the guest with
 	  timing infrastructure such as time of day, and system time
 
+config PVH
+	bool "Support for running PVH guests"
+	def_bool n
+	---help---
+	  This option enables the PVH entry point for guest virtual machines
+	  as specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
 	bool "Enable debug information for KVM Guests in debugfs"
 	depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 0f545b3cf926..fc9f678c6413 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -41,7 +41,7 @@
 
 #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
 PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
 #endif
@@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
 
 	.data
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 NEXT_PGD_PAGE(init_top_pgt)
 	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
 	.org    init_top_pgt + PGD_PAGE_OFFSET*8, 0
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index f605825a04ab..021c8591c3c0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -77,8 +77,9 @@ config XEN_DEBUG_FS
 	  Enabling this option may incur a significant performance overhead.
 
 config XEN_PVH
-	bool "Support for running as a PVH guest"
+	bool "Support for running as a Xen PVH guest"
 	depends on XEN && XEN_PVHVM && ACPI
 	# Pre-built page tables are not ready to handle 5-level paging.
 	depends on !X86_5LEVEL
+	select PVH
 	def_bool n
-- 
2.16.1


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

[PATCH v5 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files sitting at a higher level in the tree.

This patch is not introducing any code or functional changes, just moving
files from one location to another.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 MAINTAINERS                                                | 1 +
 arch/x86/Kbuild                                            | 2 ++
 arch/x86/platform/pvh/Makefile                             | 5 +++++
 arch/x86/{xen/enlighten_pvh.c => platform/pvh/enlighten.c} | 0
 arch/x86/{xen/xen-pvh.S => platform/pvh/head.S}            | 0
 arch/x86/xen/Makefile                                      | 3 ---
 6 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/platform/pvh/Makefile
 rename arch/x86/{xen/enlighten_pvh.c => platform/pvh/enlighten.c} (100%)
 rename arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..58a836f39ad4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15210,6 +15210,7 @@ L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 S:	Supported
 F:	arch/x86/xen/
+F:	arch/x86/platform/pvh/
 F:	drivers/*/xen-*front.c
 F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 0038a2d10a7a..2089e4414300 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,6 +7,8 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
+obj-$(CONFIG_XEN_PVH) += platform/pvh/
+
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
 
diff --git a/arch/x86/platform/pvh/Makefile b/arch/x86/platform/pvh/Makefile
new file mode 100644
index 000000000000..9fd25efcd2a3
--- /dev/null
+++ b/arch/x86/platform/pvh/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+OBJECT_FILES_NON_STANDARD_head.o := y
+
+obj-$(CONFIG_XEN_PVH) += enlighten.o
+obj-$(CONFIG_XEN_PVH) += head.o
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/platform/pvh/enlighten.c
similarity index 100%
rename from arch/x86/xen/enlighten_pvh.c
rename to arch/x86/platform/pvh/enlighten.c
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/platform/pvh/head.S
similarity index 100%
rename from arch/x86/xen/xen-pvh.S
rename to arch/x86/platform/pvh/head.S
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index d83cb5478f54..f1b850607212 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -1,6 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o := y
-OBJECT_FILES_NON_STANDARD_xen-pvh.o := y
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not profile debug and lowlevel utilities
@@ -21,7 +20,6 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
-obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
@@ -33,4 +31,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
 obj-$(CONFIG_XEN_DOM0)		+= vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)		+= efi.o
-obj-$(CONFIG_XEN_PVH)	 	+= xen-pvh.o
-- 
2.16.1

[PATCH v5 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files sitting at a higher level in the tree.

This patch is not introducing any code or functional changes, just moving
files from one location to another.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 MAINTAINERS                                                | 1 +
 arch/x86/Kbuild                                            | 2 ++
 arch/x86/platform/pvh/Makefile                             | 5 +++++
 arch/x86/{xen/enlighten_pvh.c => platform/pvh/enlighten.c} | 0
 arch/x86/{xen/xen-pvh.S => platform/pvh/head.S}            | 0
 arch/x86/xen/Makefile                                      | 3 ---
 6 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/platform/pvh/Makefile
 rename arch/x86/{xen/enlighten_pvh.c => platform/pvh/enlighten.c} (100%)
 rename arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..58a836f39ad4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15210,6 +15210,7 @@ L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 S:	Supported
 F:	arch/x86/xen/
+F:	arch/x86/platform/pvh/
 F:	drivers/*/xen-*front.c
 F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 0038a2d10a7a..2089e4414300 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,6 +7,8 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
+obj-$(CONFIG_XEN_PVH) += platform/pvh/
+
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
 
diff --git a/arch/x86/platform/pvh/Makefile b/arch/x86/platform/pvh/Makefile
new file mode 100644
index 000000000000..9fd25efcd2a3
--- /dev/null
+++ b/arch/x86/platform/pvh/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+OBJECT_FILES_NON_STANDARD_head.o := y
+
+obj-$(CONFIG_XEN_PVH) += enlighten.o
+obj-$(CONFIG_XEN_PVH) += head.o
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/platform/pvh/enlighten.c
similarity index 100%
rename from arch/x86/xen/enlighten_pvh.c
rename to arch/x86/platform/pvh/enlighten.c
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/platform/pvh/head.S
similarity index 100%
rename from arch/x86/xen/xen-pvh.S
rename to arch/x86/platform/pvh/head.S
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index d83cb5478f54..f1b850607212 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -1,6 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o := y
-OBJECT_FILES_NON_STANDARD_xen-pvh.o := y
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not profile debug and lowlevel utilities
@@ -21,7 +20,6 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
-obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
@@ -33,4 +31,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
 obj-$(CONFIG_XEN_DOM0)		+= vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)		+= efi.o
-obj-$(CONFIG_XEN_PVH)	 	+= xen-pvh.o
-- 
2.16.1


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

[PATCH v5 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/platform/pvh/enlighten.c |  5 ++---
 arch/x86/xen/Makefile             |  1 +
 arch/x86/xen/enlighten_pvh.c      | 10 ++++++++++
 3 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 436c4f003e17..74c0a711ebe7 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -16,10 +16,9 @@
 /*
  * PVH variables.
  *
- * xen_pvh and pvh_bootparams need to live in data segment since they
- * are used after startup_{32|64}, which clear .bss, are invoked.
+ * pvh_bootparams needs to live in the data segment since it is
+ * used after startup_{32|64}, which clear .bss, are invoked.
  */
-bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
 
 struct hvm_start_info pvh_start_info;
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index f1b850607212..ae5c6f1f0fe0 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -20,6 +20,7 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
+obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
new file mode 100644
index 000000000000..c5409c1f259f
--- /dev/null
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -0,0 +1,10 @@
+#include <linux/types.h>
+
+/*
+ * PVH variables.
+ *
+ * The variable xen_pvh needs to live in the data segment since it is used
+ * after startup_{32|64} is invoked, which will clear the .bss segment.
+ */
+bool xen_pvh __attribute__((section(".data"))) = 0;
+
-- 
2.16.1

[PATCH v5 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 arch/x86/platform/pvh/enlighten.c |  5 ++---
 arch/x86/xen/Makefile             |  1 +
 arch/x86/xen/enlighten_pvh.c      | 10 ++++++++++
 3 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 436c4f003e17..74c0a711ebe7 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -16,10 +16,9 @@
 /*
  * PVH variables.
  *
- * xen_pvh and pvh_bootparams need to live in data segment since they
- * are used after startup_{32|64}, which clear .bss, are invoked.
+ * pvh_bootparams needs to live in the data segment since it is
+ * used after startup_{32|64}, which clear .bss, are invoked.
  */
-bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
 
 struct hvm_start_info pvh_start_info;
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index f1b850607212..ae5c6f1f0fe0 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -20,6 +20,7 @@ obj-y		:= enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o mmu_hvm.o suspend_hvm.o
 obj-$(CONFIG_XEN_PV)			+= setup.o apic.o pmu.o suspend_pv.o \
 						p2m.o enlighten_pv.o mmu_pv.o
+obj-$(CONFIG_XEN_PVH)			+= enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
new file mode 100644
index 000000000000..c5409c1f259f
--- /dev/null
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -0,0 +1,10 @@
+#include <linux/types.h>
+
+/*
+ * PVH variables.
+ *
+ * The variable xen_pvh needs to live in the data segment since it is used
+ * after startup_{32|64} is invoked, which will clear the .bss segment.
+ */
+bool xen_pvh __attribute__((section(".data"))) = 0;
+
-- 
2.16.1


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

[PATCH v5 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Moving it out of the common file
is going to allow us to compile kernels in the future without CONFIG_XEN
that are still capable of being booted as a Qemu/KVM guest via the PVH
entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/platform/pvh/enlighten.c | 28 ++++++++++++++++++++--------
 arch/x86/xen/enlighten_pvh.c      | 18 +++++++++++++++++-
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 74c0a711ebe7..b463ee30517a 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
 	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
 }
 
+/*
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide the required override for this routine.
+ */
+void __init __weak xen_pvh_init(void)
+{
+	xen_raw_printk("Error: Missing xen PVH initialization\n");
+	BUG();
+}
+
+/*
+ * When we add support for other hypervisors like Qemu/KVM, this routine can
+ * selectively invoke the appropriate initialization based on guest type.
+ */
+static void hypervisor_specific_init(void)
+{
+	xen_pvh_init();
+}
+
 /*
  * This routine (and those that it might call) should not use
  * anything that lives in .bss since that segment will be cleared later.
  */
 void __init xen_prepare_pvh(void)
 {
-	u32 msr;
-	u64 pfn;
-
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	xen_pvh = 1;
-
-	msr = cpuid_ebx(xen_cpuid_base() + 2);
-	pfn = __pa(hypercall_page);
-	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+	hypervisor_specific_init();
 
 	init_pvh_bootparams();
 }
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index c5409c1f259f..08fc63d14ae5 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,4 +1,9 @@
-#include <linux/types.h>
+#include <linux/acpi.h>
+
+#include <asm/io_apic.h>
+
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
 
 /*
  * PVH variables.
@@ -8,3 +13,14 @@
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 
+void __init xen_pvh_init(void)
+{
+	u32 msr;
+	u64 pfn;
+
+	xen_pvh = 1;
+
+	msr = cpuid_ebx(xen_cpuid_base() + 2);
+	pfn = __pa(hypercall_page);
+	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+}
-- 
2.16.1

[PATCH v5 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Moving it out of the common file
is going to allow us to compile kernels in the future without CONFIG_XEN
that are still capable of being booted as a Qemu/KVM guest via the PVH
entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/platform/pvh/enlighten.c | 28 ++++++++++++++++++++--------
 arch/x86/xen/enlighten_pvh.c      | 18 +++++++++++++++++-
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 74c0a711ebe7..b463ee30517a 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
 	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
 }
 
+/*
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide the required override for this routine.
+ */
+void __init __weak xen_pvh_init(void)
+{
+	xen_raw_printk("Error: Missing xen PVH initialization\n");
+	BUG();
+}
+
+/*
+ * When we add support for other hypervisors like Qemu/KVM, this routine can
+ * selectively invoke the appropriate initialization based on guest type.
+ */
+static void hypervisor_specific_init(void)
+{
+	xen_pvh_init();
+}
+
 /*
  * This routine (and those that it might call) should not use
  * anything that lives in .bss since that segment will be cleared later.
  */
 void __init xen_prepare_pvh(void)
 {
-	u32 msr;
-	u64 pfn;
-
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	xen_pvh = 1;
-
-	msr = cpuid_ebx(xen_cpuid_base() + 2);
-	pfn = __pa(hypercall_page);
-	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+	hypervisor_specific_init();
 
 	init_pvh_bootparams();
 }
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index c5409c1f259f..08fc63d14ae5 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,4 +1,9 @@
-#include <linux/types.h>
+#include <linux/acpi.h>
+
+#include <asm/io_apic.h>
+
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
 
 /*
  * PVH variables.
@@ -8,3 +13,14 @@
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 
+void __init xen_pvh_init(void)
+{
+	u32 msr;
+	u64 pfn;
+
+	xen_pvh = 1;
+
+	msr = cpuid_ebx(xen_cpuid_base() + 2);
+	pfn = __pa(hypercall_page);
+	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+}
-- 
2.16.1


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

[PATCH v5 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
a new mechanism will be added that allows the guest to get the memory
map without needing to use hypercalls.

For Xen guests, the hypercall approach will still be supported. In
preparation for adding support for other hypervisors, we can move the
code that uses hypercalls into the Xen specific file. This will allow us
to compile kernels in the future without CONFIG_XEN that are still capable
of being booted as a Qemu/KVM guest via the PVH entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/platform/pvh/enlighten.c | 28 ++++++++++++++--------------
 arch/x86/xen/enlighten_pvh.c      | 20 ++++++++++++++++++++
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index b463ee30517a..347ecb1860d5 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -7,9 +7,6 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
-#include <asm/xen/interface.h>
-#include <asm/xen/hypercall.h>
-
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -24,21 +21,24 @@ struct boot_params pvh_bootparams __attribute__((section(".data")));
 struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
+/*
+ * Xen guests are able to obtain the memory map from the hypervisor via the
+ * HYPERVISOR_memory_op hypercall.
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide an override for this routine to do
+ * just that.
+ */
+void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
+{
+	xen_raw_printk("Error: Could not find memory map\n");
+	BUG();
+}
+
 static void __init init_pvh_bootparams(void)
 {
-	struct xen_memory_map memmap;
-	int rc;
-
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
-	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
-	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
-	if (rc) {
-		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-		BUG();
-	}
-	pvh_bootparams.e820_entries = memmap.nr_entries;
+	mem_map_via_hcall(&pvh_bootparams);
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 08fc63d14ae5..00658d4bc4f4 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,10 +1,15 @@
 #include <linux/acpi.h>
 
+#include <xen/hvc-console.h>
+
 #include <asm/io_apic.h>
+#include <asm/e820/api.h>
 
 #include <asm/xen/interface.h>
 #include <asm/xen/hypercall.h>
 
+#include <xen/interface/memory.h>
+
 /*
  * PVH variables.
  *
@@ -24,3 +29,18 @@ void __init xen_pvh_init(void)
 	pfn = __pa(hypercall_page);
 	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 }
+
+void __init mem_map_via_hcall(struct boot_params *boot_params_p)
+{
+	struct xen_memory_map memmap;
+	int rc;
+
+	memmap.nr_entries = ARRAY_SIZE(boot_params_p->e820_table);
+	set_xen_guest_handle(memmap.buffer, boot_params_p->e820_table);
+	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
+	if (rc) {
+		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+		BUG();
+	}
+	boot_params_p->e820_entries = memmap.nr_entries;
+}
-- 
2.16.1

[PATCH v5 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
a new mechanism will be added that allows the guest to get the memory
map without needing to use hypercalls.

For Xen guests, the hypercall approach will still be supported. In
preparation for adding support for other hypervisors, we can move the
code that uses hypercalls into the Xen specific file. This will allow us
to compile kernels in the future without CONFIG_XEN that are still capable
of being booted as a Qemu/KVM guest via the PVH entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/platform/pvh/enlighten.c | 28 ++++++++++++++--------------
 arch/x86/xen/enlighten_pvh.c      | 20 ++++++++++++++++++++
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index b463ee30517a..347ecb1860d5 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -7,9 +7,6 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
-#include <asm/xen/interface.h>
-#include <asm/xen/hypercall.h>
-
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -24,21 +21,24 @@ struct boot_params pvh_bootparams __attribute__((section(".data")));
 struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
+/*
+ * Xen guests are able to obtain the memory map from the hypervisor via the
+ * HYPERVISOR_memory_op hypercall.
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide an override for this routine to do
+ * just that.
+ */
+void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
+{
+	xen_raw_printk("Error: Could not find memory map\n");
+	BUG();
+}
+
 static void __init init_pvh_bootparams(void)
 {
-	struct xen_memory_map memmap;
-	int rc;
-
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
-	set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
-	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
-	if (rc) {
-		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-		BUG();
-	}
-	pvh_bootparams.e820_entries = memmap.nr_entries;
+	mem_map_via_hcall(&pvh_bootparams);
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 08fc63d14ae5..00658d4bc4f4 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,10 +1,15 @@
 #include <linux/acpi.h>
 
+#include <xen/hvc-console.h>
+
 #include <asm/io_apic.h>
+#include <asm/e820/api.h>
 
 #include <asm/xen/interface.h>
 #include <asm/xen/hypercall.h>
 
+#include <xen/interface/memory.h>
+
 /*
  * PVH variables.
  *
@@ -24,3 +29,18 @@ void __init xen_pvh_init(void)
 	pfn = __pa(hypercall_page);
 	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 }
+
+void __init mem_map_via_hcall(struct boot_params *boot_params_p)
+{
+	struct xen_memory_map memmap;
+	int rc;
+
+	memmap.nr_entries = ARRAY_SIZE(boot_params_p->e820_table);
+	set_xen_guest_handle(memmap.buffer, boot_params_p->e820_table);
+	rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
+	if (rc) {
+		xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+		BUG();
+	}
+	boot_params_p->e820_entries = memmap.nr_entries;
+}
-- 
2.16.1


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

[PATCH v5 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 include/xen/interface/hvm/start_info.h | 65 +++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/hvm/start_info.h b/include/xen/interface/hvm/start_info.h
index 648415976ead..d491f2d89393 100644
--- a/include/xen/interface/hvm/start_info.h
+++ b/include/xen/interface/hvm/start_info.h
@@ -33,7 +33,7 @@
  *    | magic          | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *    |                | ("xEn3" with the 0x80 bit of the "E" set).
  *  4 +----------------+
- *    | version        | Version of this structure. Current version is 0. New
+ *    | version        | Version of this structure. Current version is 1. New
  *    |                | versions are guaranteed to be backwards-compatible.
  *  8 +----------------+
  *    | flags          | SIF_xxx flags.
@@ -48,6 +48,15 @@
  * 32 +----------------+
  *    | rsdp_paddr     | Physical address of the RSDP ACPI data structure.
  * 40 +----------------+
+ *    | memmap_paddr   | Physical address of the (optional) memory map. Only
+ *    |                | present in version 1 and newer of the structure.
+ * 48 +----------------+
+ *    | memmap_entries | Number of entries in the memory map table. Zero
+ *    |                | if there is no memory map being provided. Only
+ *    |                | present in version 1 and newer of the structure.
+ * 52 +----------------+
+ *    | reserved       | Version 1 and newer only.
+ * 56 +----------------+
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,13 +71,52 @@
  *    | reserved       |
  * 32 +----------------+
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 +----------------+
+ *    | addr           | Base address
+ *  8 +----------------+
+ *    | size           | Size of mapping in bytes
+ * 16 +----------------+
+ *    | type           | Type of mapping as defined between the hypervisor
+ *    |                | and guest it's starting. See XEN_HVM_MEMMAP_TYPE_*
+ *    |                | values below.
+ * 20 +----------------|
+ *    | reserved       |
+ * 24 +----------------+
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:  Initial implementation.
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ *             padding) to the end of the hvm_start_info struct. These new
+ *             fields can be used to pass a memory map to the guest. The
+ *             memory map is optional and so guests that understand version 1
+ *             of the structure must check that memmap_entries is non-zero
+ *             before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
+/*
+ * The values used in the type field of the memory map table entries are
+ * defined below and match the Address Range Types as defined in the "System
+ * Address Map Interfaces" section of the ACPI Specification. Please refer to
+ * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
+ */
+#define XEN_HVM_MEMMAP_TYPE_RAM       1
+#define XEN_HVM_MEMMAP_TYPE_RESERVED  2
+#define XEN_HVM_MEMMAP_TYPE_ACPI      3
+#define XEN_HVM_MEMMAP_TYPE_NVS       4
+#define XEN_HVM_MEMMAP_TYPE_UNUSABLE  5
+#define XEN_HVM_MEMMAP_TYPE_DISABLED  6
+#define XEN_HVM_MEMMAP_TYPE_PMEM      7
+
 /*
  * C representation of the x86/HVM start info layout.
  *
@@ -86,6 +134,14 @@ struct hvm_start_info {
     uint64_t cmdline_paddr;     /* Physical address of the command line.     */
     uint64_t rsdp_paddr;        /* Physical address of the RSDP ACPI data    */
                                 /* structure.                                */
+    uint64_t memmap_paddr;      /* Physical address of an array of           */
+                                /* hvm_memmap_table_entry. Only present in   */
+                                /* version 1 and newer of the structure      */
+    uint32_t memmap_entries;    /* Number of entries in the memmap table.    */
+                                /* Only present in version 1 and newer of    */
+                                /* the structure. Value will be zero if      */
+                                /* there is no memory map being provided.    */
+    uint32_t reserved;          /* Must be zero for Version 1.               */
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +151,11 @@ struct hvm_modlist_entry {
     uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+    uint64_t addr;              /* Base address of the memory region         */
+    uint64_t size;              /* Size of the memory region in bytes        */
+    uint32_t type;              /* Mapping type                              */
+    uint32_t reserved;          /* Must be zero for Version 1.               */
+};
+
 #endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
-- 
2.16.1

[PATCH v5 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
---
 include/xen/interface/hvm/start_info.h | 65 +++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/hvm/start_info.h b/include/xen/interface/hvm/start_info.h
index 648415976ead..d491f2d89393 100644
--- a/include/xen/interface/hvm/start_info.h
+++ b/include/xen/interface/hvm/start_info.h
@@ -33,7 +33,7 @@
  *    | magic          | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *    |                | ("xEn3" with the 0x80 bit of the "E" set).
  *  4 +----------------+
- *    | version        | Version of this structure. Current version is 0. New
+ *    | version        | Version of this structure. Current version is 1. New
  *    |                | versions are guaranteed to be backwards-compatible.
  *  8 +----------------+
  *    | flags          | SIF_xxx flags.
@@ -48,6 +48,15 @@
  * 32 +----------------+
  *    | rsdp_paddr     | Physical address of the RSDP ACPI data structure.
  * 40 +----------------+
+ *    | memmap_paddr   | Physical address of the (optional) memory map. Only
+ *    |                | present in version 1 and newer of the structure.
+ * 48 +----------------+
+ *    | memmap_entries | Number of entries in the memory map table. Zero
+ *    |                | if there is no memory map being provided. Only
+ *    |                | present in version 1 and newer of the structure.
+ * 52 +----------------+
+ *    | reserved       | Version 1 and newer only.
+ * 56 +----------------+
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,13 +71,52 @@
  *    | reserved       |
  * 32 +----------------+
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 +----------------+
+ *    | addr           | Base address
+ *  8 +----------------+
+ *    | size           | Size of mapping in bytes
+ * 16 +----------------+
+ *    | type           | Type of mapping as defined between the hypervisor
+ *    |                | and guest it's starting. See XEN_HVM_MEMMAP_TYPE_*
+ *    |                | values below.
+ * 20 +----------------|
+ *    | reserved       |
+ * 24 +----------------+
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:  Initial implementation.
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ *             padding) to the end of the hvm_start_info struct. These new
+ *             fields can be used to pass a memory map to the guest. The
+ *             memory map is optional and so guests that understand version 1
+ *             of the structure must check that memmap_entries is non-zero
+ *             before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
+/*
+ * The values used in the type field of the memory map table entries are
+ * defined below and match the Address Range Types as defined in the "System
+ * Address Map Interfaces" section of the ACPI Specification. Please refer to
+ * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
+ */
+#define XEN_HVM_MEMMAP_TYPE_RAM       1
+#define XEN_HVM_MEMMAP_TYPE_RESERVED  2
+#define XEN_HVM_MEMMAP_TYPE_ACPI      3
+#define XEN_HVM_MEMMAP_TYPE_NVS       4
+#define XEN_HVM_MEMMAP_TYPE_UNUSABLE  5
+#define XEN_HVM_MEMMAP_TYPE_DISABLED  6
+#define XEN_HVM_MEMMAP_TYPE_PMEM      7
+
 /*
  * C representation of the x86/HVM start info layout.
  *
@@ -86,6 +134,14 @@ struct hvm_start_info {
     uint64_t cmdline_paddr;     /* Physical address of the command line.     */
     uint64_t rsdp_paddr;        /* Physical address of the RSDP ACPI data    */
                                 /* structure.                                */
+    uint64_t memmap_paddr;      /* Physical address of an array of           */
+                                /* hvm_memmap_table_entry. Only present in   */
+                                /* version 1 and newer of the structure      */
+    uint32_t memmap_entries;    /* Number of entries in the memmap table.    */
+                                /* Only present in version 1 and newer of    */
+                                /* the structure. Value will be zero if      */
+                                /* there is no memory map being provided.    */
+    uint32_t reserved;          /* Must be zero for Version 1.               */
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +151,11 @@ struct hvm_modlist_entry {
     uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+    uint64_t addr;              /* Base address of the memory region         */
+    uint64_t size;              /* Size of the memory region in bytes        */
+    uint32_t type;              /* Mapping type                              */
+    uint32_t reserved;          /* Must be zero for Version 1.               */
+};
+
 #endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
-- 
2.16.1


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

[PATCH v5 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch enables Qemu to use that same entry point for booting KVM
guests.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/Kbuild                   |  2 +-
 arch/x86/Kconfig                  |  8 ++++++++
 arch/x86/platform/pvh/Makefile    |  4 ++--
 arch/x86/platform/pvh/enlighten.c | 43 +++++++++++++++++++++++++++++----------
 4 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 2089e4414300..c625f57472f7 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,7 +7,7 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
-obj-$(CONFIG_XEN_PVH) += platform/pvh/
+obj-$(CONFIG_PVH) += platform/pvh/
 
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 58831320b5d2..74ad956ee0f6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -798,6 +798,14 @@ config PVH
 	  This option enables the PVH entry point for guest virtual machines
 	  as specified in the x86/HVM direct boot ABI.
 
+config KVM_GUEST_PVH
+	bool "Support for running as a KVM PVH guest"
+	depends on KVM_GUEST
+	select PVH
+	---help---
+	  This option enables starting KVM guests via the PVH entry point as
+	  specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
 	bool "Enable debug information for KVM Guests in debugfs"
 	depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/platform/pvh/Makefile b/arch/x86/platform/pvh/Makefile
index 9fd25efcd2a3..5dec5067c9fb 100644
--- a/arch/x86/platform/pvh/Makefile
+++ b/arch/x86/platform/pvh/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD_head.o := y
 
-obj-$(CONFIG_XEN_PVH) += enlighten.o
-obj-$(CONFIG_XEN_PVH) += head.o
+obj-$(CONFIG_PVH) += enlighten.o
+obj-$(CONFIG_PVH) += head.o
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 347ecb1860d5..433f586d8302 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -7,6 +7,9 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
+
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -34,11 +37,28 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
 	BUG();
 }
 
-static void __init init_pvh_bootparams(void)
+static void __init init_pvh_bootparams(bool xen_guest)
 {
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	mem_map_via_hcall(&pvh_bootparams);
+	if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
+		struct hvm_memmap_table_entry *ep;
+		int i;
+
+		ep = __va(pvh_start_info.memmap_paddr);
+		pvh_bootparams.e820_entries = pvh_start_info.memmap_entries;
+
+		for (i = 0; i < pvh_bootparams.e820_entries ; i++, ep++) {
+			pvh_bootparams.e820_table[i].addr = ep->addr;
+			pvh_bootparams.e820_table[i].size = ep->size;
+			pvh_bootparams.e820_table[i].type = ep->type;
+		}
+	} else if (xen_guest) {
+		mem_map_via_hcall(&pvh_bootparams);
+	} else {
+		/* Non-xen guests are not supported by version 0 */
+		BUG();
+	}
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
@@ -69,7 +89,7 @@ static void __init init_pvh_bootparams(void)
 	 * environment (i.e. hardware_subarch 0).
 	 */
 	pvh_bootparams.hdr.version = 0x212;
-	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+	pvh_bootparams.hdr.type_of_loader = ((xen_guest ? 0x9 : 0xb) << 4) | 0;
 }
 
 /*
@@ -82,13 +102,10 @@ void __init __weak xen_pvh_init(void)
 	BUG();
 }
 
-/*
- * When we add support for other hypervisors like Qemu/KVM, this routine can
- * selectively invoke the appropriate initialization based on guest type.
- */
-static void hypervisor_specific_init(void)
+static void hypervisor_specific_init(bool xen_guest)
 {
-	xen_pvh_init();
+	if (xen_guest)
+		xen_pvh_init();
 }
 
 /*
@@ -97,13 +114,17 @@ static void hypervisor_specific_init(void)
  */
 void __init xen_prepare_pvh(void)
 {
+
+	u32 msr = xen_cpuid_base();
+	bool xen_guest = !!msr;
+
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	hypervisor_specific_init();
+	hypervisor_specific_init(xen_guest);
 
-	init_pvh_bootparams();
+	init_pvh_bootparams(xen_guest);
 }
-- 
2.16.1

[PATCH v5 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch enables Qemu to use that same entry point for booting KVM
guests.

Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Suggested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/Kbuild                   |  2 +-
 arch/x86/Kconfig                  |  8 ++++++++
 arch/x86/platform/pvh/Makefile    |  4 ++--
 arch/x86/platform/pvh/enlighten.c | 43 +++++++++++++++++++++++++++++----------
 4 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 2089e4414300..c625f57472f7 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,7 +7,7 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
-obj-$(CONFIG_XEN_PVH) += platform/pvh/
+obj-$(CONFIG_PVH) += platform/pvh/
 
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 58831320b5d2..74ad956ee0f6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -798,6 +798,14 @@ config PVH
 	  This option enables the PVH entry point for guest virtual machines
 	  as specified in the x86/HVM direct boot ABI.
 
+config KVM_GUEST_PVH
+	bool "Support for running as a KVM PVH guest"
+	depends on KVM_GUEST
+	select PVH
+	---help---
+	  This option enables starting KVM guests via the PVH entry point as
+	  specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
 	bool "Enable debug information for KVM Guests in debugfs"
 	depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/platform/pvh/Makefile b/arch/x86/platform/pvh/Makefile
index 9fd25efcd2a3..5dec5067c9fb 100644
--- a/arch/x86/platform/pvh/Makefile
+++ b/arch/x86/platform/pvh/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD_head.o := y
 
-obj-$(CONFIG_XEN_PVH) += enlighten.o
-obj-$(CONFIG_XEN_PVH) += head.o
+obj-$(CONFIG_PVH) += enlighten.o
+obj-$(CONFIG_PVH) += head.o
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 347ecb1860d5..433f586d8302 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -7,6 +7,9 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 
+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
+
 #include <xen/interface/memory.h>
 #include <xen/interface/hvm/start_info.h>
 
@@ -34,11 +37,28 @@ void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
 	BUG();
 }
 
-static void __init init_pvh_bootparams(void)
+static void __init init_pvh_bootparams(bool xen_guest)
 {
 	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
-	mem_map_via_hcall(&pvh_bootparams);
+	if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
+		struct hvm_memmap_table_entry *ep;
+		int i;
+
+		ep = __va(pvh_start_info.memmap_paddr);
+		pvh_bootparams.e820_entries = pvh_start_info.memmap_entries;
+
+		for (i = 0; i < pvh_bootparams.e820_entries ; i++, ep++) {
+			pvh_bootparams.e820_table[i].addr = ep->addr;
+			pvh_bootparams.e820_table[i].size = ep->size;
+			pvh_bootparams.e820_table[i].type = ep->type;
+		}
+	} else if (xen_guest) {
+		mem_map_via_hcall(&pvh_bootparams);
+	} else {
+		/* Non-xen guests are not supported by version 0 */
+		BUG();
+	}
 
 	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
 		pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
@@ -69,7 +89,7 @@ static void __init init_pvh_bootparams(void)
 	 * environment (i.e. hardware_subarch 0).
 	 */
 	pvh_bootparams.hdr.version = 0x212;
-	pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+	pvh_bootparams.hdr.type_of_loader = ((xen_guest ? 0x9 : 0xb) << 4) | 0;
 }
 
 /*
@@ -82,13 +102,10 @@ void __init __weak xen_pvh_init(void)
 	BUG();
 }
 
-/*
- * When we add support for other hypervisors like Qemu/KVM, this routine can
- * selectively invoke the appropriate initialization based on guest type.
- */
-static void hypervisor_specific_init(void)
+static void hypervisor_specific_init(bool xen_guest)
 {
-	xen_pvh_init();
+	if (xen_guest)
+		xen_pvh_init();
 }
 
 /*
@@ -97,13 +114,17 @@ static void hypervisor_specific_init(void)
  */
 void __init xen_prepare_pvh(void)
 {
+
+	u32 msr = xen_cpuid_base();
+	bool xen_guest = !!msr;
+
 	if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
 		xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
 				pvh_start_info.magic);
 		BUG();
 	}
 
-	hypervisor_specific_init();
+	hypervisor_specific_init(xen_guest);
 
-	init_pvh_bootparams();
+	init_pvh_bootparams(xen_guest);
 }
-- 
2.16.1


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

Re: [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Randy Dunlap]

Hi,

On 03/20/2018 12:18 PM, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH

                                                 than

> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/Kconfig          | 7 +++++++
>  arch/x86/kernel/head_64.S | 4 ++--
>  arch/x86/xen/Kconfig      | 3 ++-
>  3 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..58831320b5d2 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,13 @@ config KVM_GUEST
>  	  underlying device model, the host provides the guest with
>  	  timing infrastructure such as time of day, and system time
>  
> +config PVH
> +	bool "Support for running PVH guests"
> +	def_bool n

You don't need two (2) "bool"s here. And 'n' is already the default, so just
drop the second line.

> +	---help---
> +	  This option enables the PVH entry point for guest virtual machines
> +	  as specified in the x86/HVM direct boot ABI.
> +
>  config KVM_DEBUG_FS
>  	bool "Enable debug information for KVM Guests in debugfs"
>  	depends on KVM_GUEST && DEBUG_FS


-- 
~Randy

Re: [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Randy Dunlap]

Hi,

On 03/20/2018 12:18 PM, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH

                                                 than

> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
> ---
>  arch/x86/Kconfig          | 7 +++++++
>  arch/x86/kernel/head_64.S | 4 ++--
>  arch/x86/xen/Kconfig      | 3 ++-
>  3 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..58831320b5d2 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,13 @@ config KVM_GUEST
>  	  underlying device model, the host provides the guest with
>  	  timing infrastructure such as time of day, and system time
>  
> +config PVH
> +	bool "Support for running PVH guests"
> +	def_bool n

You don't need two (2) "bool"s here. And 'n' is already the default, so just
drop the second line.

> +	---help---
> +	  This option enables the PVH entry point for guest virtual machines
> +	  as specified in the x86/HVM direct boot ABI.
> +
>  config KVM_DEBUG_FS
>  	bool "Enable debug information for KVM Guests in debugfs"
>  	depends on KVM_GUEST && DEBUG_FS


-- 
~Randy

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

Re: [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

On 3/20/2018 12:23 PM, Randy Dunlap wrote:
> Hi,
>
> On 03/20/2018 12:18 PM, Maran Wilson wrote:
>> In order to pave the way for hypervisors other then Xen to use the PVH
>                                                   than
>
>> entry point for VMs, we need to factor the PVH entry code into Xen specific
>> and hypervisor agnostic components. The first step in doing that, is to
>> create a new config option for PVH entry that can be enabled
>> independently from CONFIG_XEN.
>>
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> ---
>>   arch/x86/Kconfig          | 7 +++++++
>>   arch/x86/kernel/head_64.S | 4 ++--
>>   arch/x86/xen/Kconfig      | 3 ++-
>>   3 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eb7f43f23521..58831320b5d2 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -791,6 +791,13 @@ config KVM_GUEST
>>   	  underlying device model, the host provides the guest with
>>   	  timing infrastructure such as time of day, and system time
>>   
>> +config PVH
>> +	bool "Support for running PVH guests"
>> +	def_bool n
> You don't need two (2) "bool"s here. And 'n' is already the default, so just
> drop the second line.
>
>> +	---help---
>> +	  This option enables the PVH entry point for guest virtual machines
>> +	  as specified in the x86/HVM direct boot ABI.
>> +
>>   config KVM_DEBUG_FS
>>   	bool "Enable debug information for KVM Guests in debugfs"
>>   	depends on KVM_GUEST && DEBUG_FS
>

Hi Randy,

Will make both changes.

Thanks,
-Maran

Re: [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

On 3/20/2018 12:23 PM, Randy Dunlap wrote:
> Hi,
>
> On 03/20/2018 12:18 PM, Maran Wilson wrote:
>> In order to pave the way for hypervisors other then Xen to use the PVH
>                                                   than
>
>> entry point for VMs, we need to factor the PVH entry code into Xen specific
>> and hypervisor agnostic components. The first step in doing that, is to
>> create a new config option for PVH entry that can be enabled
>> independently from CONFIG_XEN.
>>
>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>> ---
>>   arch/x86/Kconfig          | 7 +++++++
>>   arch/x86/kernel/head_64.S | 4 ++--
>>   arch/x86/xen/Kconfig      | 3 ++-
>>   3 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eb7f43f23521..58831320b5d2 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -791,6 +791,13 @@ config KVM_GUEST
>>   	  underlying device model, the host provides the guest with
>>   	  timing infrastructure such as time of day, and system time
>>   
>> +config PVH
>> +	bool "Support for running PVH guests"
>> +	def_bool n
> You don't need two (2) "bool"s here. And 'n' is already the default, so just
> drop the second line.
>
>> +	---help---
>> +	  This option enables the PVH entry point for guest virtual machines
>> +	  as specified in the x86/HVM direct boot ABI.
>> +
>>   config KVM_DEBUG_FS
>>   	bool "Enable debug information for KVM Guests in debugfs"
>>   	depends on KVM_GUEST && DEBUG_FS
>

Hi Randy,

Will make both changes.

Thanks,
-Maran

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