LinuxLists.cc - [PATCH v6 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

2018-04-04 20:30:03

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

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.

Changes from v5:

* The interface changes to the x86/HVM start info layout have
now been accepted into the Xen tree.
* Rebase and merge upstream PVH file changes.
* (Patch 6) Synced up to the final version of the header file that was
acked and pulled into the Xen tree.
* (Patch 1) Fixed typo and removed redundant "def_bool n" line.

Changes from v4:

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.

* 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.

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 | 14 +++
arch/x86/kernel/head_64.S | 2 +-
arch/x86/platform/pvh/Makefile | 5 +
arch/x86/platform/pvh/enlighten.c | 138 ++++++++++++++++++++++++
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 | 94 +++-------------
include/xen/interface/hvm/start_info.h | 63 ++++++++++-
11 files changed, 242 insertions(+), 82 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

2018-04-04 20:33:36

by Maran Wilson

[permalink] [raw]

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

In order to pave the way for hypervisors other than 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 <[email protected]>
---
arch/x86/Kconfig | 6 ++++++
arch/x86/kernel/head_64.S | 2 +-
arch/x86/xen/Kconfig | 3 ++-
3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 27fede438959..e3b836d7ad09 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -781,6 +781,12 @@ 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"
+ ---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 48385c1074a5..d83f2b110b47 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -385,7 +385,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 + L4_PAGE_OFFSET*8, 0
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c1f98f32c45f..5fccee76f44d 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -74,6 +74,7 @@ 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
+ select PVH
def_bool n
--
2.16.1

2018-04-04 20:33:36

by Maran Wilson

[permalink] [raw]

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

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 <[email protected]>
Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
---
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 65ab509e4a42..52afae73beab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15189,6 +15189,7 @@ L: [email protected] (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

2018-04-04 20:34:51

by Maran Wilson

[permalink] [raw]

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

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 <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
---
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 edcff7de0529..efbceba8db4f 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -8,9 +8,6 @@
#include <asm/e820/api.h>
#include <asm/x86_init.h>

-#include <asm/xen/interface.h>
-#include <asm/xen/hypercall.h>
-
#include <xen/interface/memory.h>
#include <xen/interface/hvm/start_info.h>

@@ -30,21 +27,24 @@ static u64 pvh_get_root_pointer(void)
return pvh_start_info.rsdp_paddr;
}

+/*
+ * 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

2018-04-04 20:35:25

by Maran Wilson

[permalink] [raw]

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

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 <[email protected]>
---
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 aa1c6a6831a9..74ff1c3d2789 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -17,10 +17,9 @@
/*
* PVH variables.
*
- * xen_pvh pvh_bootparams and pvh_start_info need to live in data segment
- * since they are used after startup_{32|64}, which clear .bss, are invoked.
+ * pvh_bootparams and pvh_start_info need to live in the 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 __attribute__((section(".data")));

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

2018-04-04 20:35:47

by Maran Wilson

[permalink] [raw]

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

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 <[email protected]>
Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
---
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 74ff1c3d2789..edcff7de0529 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -80,26 +80,38 @@ static void __init init_pvh_bootparams(void)
x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
}

+/*
+ * 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

2018-04-04 20:36:20

by Maran Wilson

[permalink] [raw]

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

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 <[email protected]>
Suggested-by: Konrad Rzeszutek Wilk <[email protected]>
Suggested-by: Boris Ostrovsky <[email protected]>
Tested-by: Boris Ostrovsky <[email protected]>
---
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 e3b836d7ad09..1e6d83e181b5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -787,6 +787,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 efbceba8db4f..815a09ad625c 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -8,6 +8,9 @@
#include <asm/e820/api.h>
#include <asm/x86_init.h>

+#include <asm/xen/interface.h>
+#include <asm/xen/hypercall.h>
+
#include <xen/interface/memory.h>
#include <xen/interface/hvm/start_info.h>

@@ -40,11 +43,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 =
@@ -75,7 +95,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;

x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
}
@@ -90,13 +110,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();
}

/*
@@ -105,13 +122,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

2018-04-04 20:36:55

by Maran Wilson

[permalink] [raw]

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

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 <[email protected]>
---
include/xen/interface/hvm/start_info.h | 63 +++++++++++++++++++++++++++++++++-
1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/hvm/start_info.h b/include/xen/interface/hvm/start_info.h
index 648415976ead..50af9ea2ff1e 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,51 @@
* | 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. 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 +133,13 @@ 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. */
+ /* All following fields only present in version 1 and newer */
+ uint64_t memmap_paddr; /* Physical address of an array of */
+ /* hvm_memmap_table_entry. */
+ uint32_t memmap_entries; /* Number of entries in the memmap table. */
+ /* Value will be zero if there is no memory */
+ /* map being provided. */
+ uint32_t reserved; /* Must be zero. */
};

struct hvm_modlist_entry {
@@ -95,4 +149,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

2018-04-05 10:02:29

by kernel test robot

[permalink] [raw]

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

Hi Maran,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on next-20180404]
[cannot apply to tip/x86/core xen-tip/linux-next v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url: https://github.com/0day-ci/linux/commits/Maran-Wilson/KVM-x86-Allow-Qemu-KVM-to-use-PVH-entry-point/20180405-165048
config: i386-randconfig-x019-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386

All errors (new ones prefixed by >>):

arch/x86/xen/enlighten_pvh.c: In function 'xen_pvh_init':
>> arch/x86/xen/enlighten_pvh.c:23:18: error: implicit declaration of function 'xen_cpuid_base'; did you mean 'get_pid_task'? [-Werror=implicit-function-declaration]
msr = cpuid_ebx(xen_cpuid_base() + 2);
^~~~~~~~~~~~~~
get_pid_task
cc1: some warnings being treated as errors

vim +23 arch/x86/xen/enlighten_pvh.c

15
16 void __init xen_pvh_init(void)
17 {
18 u32 msr;
19 u64 pfn;
20
21 xen_pvh = 1;
22
> 23 msr = cpuid_ebx(xen_cpuid_base() + 2);

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation

Attachments:

(No filename) (1.42 kB)
.config.gz (31.23 kB)
Download all attachments

2018-04-05 10:40:47

by kernel test robot

[permalink] [raw]

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

Hi Maran,

Thank you for the patch! Perhaps
[auto build test WARNING on linus/master]
url: ---
0-DAY kernel test infrastructure https://github.com/0day-ci/linux/commits/Maran-Wilson/KVM-x86-Allow-Qemu-KVM-to-use-PVH-entry-point/20180405-165048
as .config)
7.3.0
to linux build tree
>>):
/pvh/enlighten.c:12:0:
In function 'HYPERVISOR_update_va_mapping':
warning: right shift count >= width of type [-Wshift-count-overflow]
>> 32, flags);
^
note: in definition of macro '__HYPERCALL_3ARG'
= (unsigned long)(a3);
^~
note: in expansion of macro '__HYPERCALL_4ARG'
\
note: in expansion of macro '_hypercall4'
va,
In function 'HYPERVISOR_update_va_mapping_otherdomain':
warning: right shift count >= width of type [-Wshift-count-overflow]
>> 32,
^
note: in definition of macro '__HYPERCALL_3ARG'
= (unsigned long)(a3);
^~
note: in expansion of macro '__HYPERCALL_4ARG'
__arg5 = (unsigned long)(a5);
note: in expansion of macro '__HYPERCALL_5ARG'
\
note: in expansion of macro '_hypercall5'
pping_otherdomain, va,
In function 'MULTI_update_va_mapping':
warning: right shift count >= width of type [-Wshift-count-overflow]
>> 32;
In function 'MULTI_update_va_mapping_otherdomain':
warning: right shift count >= width of type [-Wshift-count-overflow]
>> 32;
/> Jeremy Fitzhardinge 2007-07-17 188
Jeremy Fitzhardinge 2007-07-17 189 #define _hypercall4(type, name, a1, a2, a3, a4) \
Jeremy Fitzhardinge 2007-07-17 190 ({ \
Jeremy Fitzhardinge 2008-07-08 191 __HYPERCALL_DECLS; \
Jeremy Fitzhardinge 2008-07-08 @192 __HYPERCALL_4ARG(a1, a2, a3, a4); \
Jeremy Fitzhardinge 2008-07-08 193 asm volatile (__HYPERCALL \
Jeremy Fitzhardinge 2008-07-08 194 : __HYPERCALL_4PARAM \
Jeremy Fitzhardinge 2008-07-08 195 : __HYPERCALL_ENTRY(name) \
Jeremy Fitzhardinge 2008-07-08 196 : __HYPERCALL_CLOBBER4); \
Jeremy Fitzhardinge 2007-07-17 197 (type)__res; \
Jeremy Fitzhardinge 2007-07-17 198 })
Jeremy Fitzhardinge 2007-07-17 199
Jeremy Fitzhardinge 2007-07-17 200 #define _hypercall5(type, name, a1, a2, a3, a4, a5) \
Jeremy Fitzhardinge 2007-07-17 201 ({ \
Jeremy Fitzhardinge 2008-07-08 202 __HYPERCALL_DECLS; \
Jeremy Fitzhardinge 2008-07-08 @203 __HYPERCALL_5ARG(a1, a2, a3, a4, a5); \
Jeremy Fitzhardinge 2008-07-08 204 asm volatile (__HYPERCALL \
Jeremy Fitzhardinge 2008-07-08 205 : __HYPERCALL_5PARAM \
Jeremy Fitzhardinge 2008-07-08 206 : __HYPERCALL_ENTRY(name) \
Jeremy Fitzhardinge 2008-07-08 207 : __HYPERCALL_CLOBBER5); \
Jeremy Fitzhardinge 2007-07-17 208 (type)__res; \
Jeremy Fitzhardinge 2007-07-17 209 })
Jeremy Fitzhardinge 2007-07-17 210
Jeremy Fitzhardinge 2009-02-09 211 static inline long
Jeremy Fitzhardinge 2009-02-09 212 privcmd_call(unsigned call,
Jeremy Fitzhardinge 2009-02-09 213 unsigned long a1, unsigned long a2,
Jeremy Fitzhardinge 2009-02-09 214 unsigned long a3, unsigned long a4,
Jeremy Fitzhardinge 2009-02-09 215 unsigned long a5)
Jeremy Fitzhardinge 2009-02-09 216 {
Jeremy Fitzhardinge 2009-02-09 217 __HYPERCALL_DECLS;
Jeremy Fitzhardinge 2009-02-09 218 __HYPERCALL_5ARG(a1, a2, a3, a4, a5);
Jeremy Fitzhardinge 2009-02-09 219
Marek Marczykowski-G?recki 2017-06-26 220 stac();
David Woodhouse 2018-01-11 221 asm volatile(CALL_NOSPEC
Jeremy Fitzhardinge 2009-02-09 222 : __HYPERCALL_5PARAM
David Woodhouse 2018-01-11 223 : [thunk_target] "a" (&hypercall_page[call])
Jeremy Fitzhardinge 2009-02-09 224 : __HYPERCALL_CLOBBER5);
Marek Marczykowski-G?recki 2017-06-26 225 clac();
Jeremy Fitzhardinge 2009-02-09 226
Jeremy Fitzhardinge 2009-02-09 227 return (long)__res;
Jeremy Fitzhardinge 2009-02-09 228 }
Jeremy Fitzhardinge 2009-02-09 229
Jeremy Fitzhardinge 2007-07-17 230 static inline int
Jeremy Fitzhardinge 2007-07-17 231 HYPERVISOR_set_trap_table(struct trap_info *table)
Jeremy Fitzhardinge 2007-07-17 232 {
Jeremy Fitzhardinge 2007-07-17 233 return _hypercall1(int, set_trap_table, table);
Jeremy Fitzhardinge 2007-07-17 234 }
Jeremy Fitzhardinge 2007-07-17 235
Jeremy Fitzhardinge 2007-07-17 236 static inline int
Jeremy Fitzhardinge 2007-07-17 237 HYPERVISOR_mmu_update(struct mmu_update *req, int count,
Jeremy Fitzhardinge 2007-07-17 238 int *success_count, domid_t domid)
Jeremy Fitzhardinge 2007-07-17 239 {
Jeremy Fitzhardinge 2007-07-17 240 return _hypercall4(int, mmu_update, req, count, success_count, domid);
Jeremy Fitzhardinge 2007-07-17 241 }
Jeremy Fitzhardinge 2007-07-17 242
Jeremy Fitzhardinge 2007-07-17 243 static inline int
Jeremy Fitzhardinge 2007-07-17 244 HYPERVISOR_mmuext_op(struct mmuext_op *op, int count,
Jeremy Fitzhardinge 2007-07-17 245 int *success_count, domid_t domid)
Jeremy Fitzhardinge 2007-07-17 246 {
Jeremy Fitzhardinge 2007-07-17 247 return _hypercall4(int, mmuext_op, op, count, success_count, domid);
Jeremy Fitzhardinge 2007-07-17 248 }
Jeremy Fitzhardinge 2007-07-17 249
Jeremy Fitzhardinge 2007-07-17 250 static inline int
Jeremy Fitzhardinge 2007-07-17 251 HYPERVISOR_set_gdt(unsigned long *frame_list, int entries)
Jeremy Fitzhardinge 2007-07-17 252 {
Jeremy Fitzhardinge 2007-07-17 253 return _hypercall2(int, set_gdt, frame_list, entries);
Jeremy Fitzhardinge 2007-07-17 254 }
Jeremy Fitzhardinge 2007-07-17 255
Jeremy Fitzhardinge 2007-07-17 256 static inline int
Jeremy Fitzhardinge 2007-07-17 257 HYPERVISOR_stack_switch(unsigned long ss, unsigned long esp)
Jeremy Fitzhardinge 2007-07-17 258 {
Jeremy Fitzhardinge 2007-07-17 259 return _hypercall2(int, stack_switch, ss, esp);
Jeremy Fitzhardinge 2007-07-17 260 }
Jeremy Fitzhardinge 2007-07-17 261
Jeremy Fitzhardinge 2008-07-08 262 #ifdef CONFIG_X86_32
Jeremy Fitzhardinge 2007-07-17 263 static inline int
Jeremy Fitzhardinge 2007-07-17 264 HYPERVISOR_set_callbacks(unsigned long event_selector,
Jeremy Fitzhardinge 2007-07-17 265 unsigned long event_address,
Jeremy Fitzhardinge 2007-07-17 266 unsigned long failsafe_selector,
Jeremy Fitzhardinge 2007-07-17 267 unsigned long failsafe_address)
Jeremy Fitzhardinge 2007-07-17 268 {
Jeremy Fitzhardinge 2007-07-17 269 return _hypercall4(int, set_callbacks,
Jeremy Fitzhardinge 2007-07-17 270 event_selector, event_address,
Jeremy Fitzhardinge 2007-07-17 271 failsafe_selector, failsafe_address);
Jeremy Fitzhardinge 2007-07-17 272 }
Jeremy Fitzhardinge 2008-07-08 273 #else /* CONFIG_X86_64 */
Jeremy Fitzhardinge 2008-07-08 274 static inline int
Jeremy Fitzhardinge 2008-07-08 275 HYPERVISOR_set_callbacks(unsigned long event_address,
Jeremy Fitzhardinge 2008-07-08 276 unsigned long failsafe_address,
Jeremy Fitzhardinge 2008-07-08 277 unsigned long syscall_address)
Jeremy Fitzhardinge 2008-07-08 278 {
Jeremy Fitzhardinge 2008-07-08 279 return _hypercall3(int, set_callbacks,
Jeremy Fitzhardinge 2008-07-08 280 event_address, failsafe_address,
Jeremy Fitzhardinge 2008-07-08 281 syscall_address);
Jeremy Fitzhardinge 2008-07-08 282 }
Jeremy Fitzhardinge 2008-07-08 283 #endif /* CONFIG_X86_{32,64} */
Jeremy Fitzhardinge 2007-07-17 284
Jeremy Fitzhardinge 2007-07-17 285 static inline int
Jeremy Fitzhardinge 2008-03-17 286 HYPERVISOR_callback_op(int cmd, void *arg)
Jeremy Fitzhardinge 2008-03-17 287 {
Jeremy Fitzhardinge 2008-03-17 288 return _hypercall2(int, callback_op, cmd, arg);
Jeremy Fitzhardinge 2008-03-17 289 }
Jeremy Fitzhardinge 2008-03-17 290
Jeremy Fitzhardinge 2008-03-17 291 static inline int
Jeremy Fitzhardinge 2007-07-17 292 HYPERVISOR_fpu_taskswitch(int set)
Jeremy Fitzhardinge 2007-07-17 293 {
Jeremy Fitzhardinge 2007-07-17 294 return _hypercall1(int, fpu_taskswitch, set);
Jeremy Fitzhardinge 2007-07-17 295 }
Jeremy Fitzhardinge 2007-07-17 296
Jeremy Fitzhardinge 2007-07-17 297 static inline int
Jeremy Fitzhardinge 2008-05-26 298 HYPERVISOR_sched_op(int cmd, void *arg)
Jeremy Fitzhardinge 2007-07-17 299 {
Ian Campbell 2011-02-17 300 return _hypercall2(int, sched_op, cmd, arg);
Jeremy Fitzhardinge 2007-07-17 301 }
Jeremy Fitzhardinge 2007-07-17 302
Jeremy Fitzhardinge 2007-07-17 303 static inline long
Jeremy Fitzhardinge 2007-07-17 304 HYPERVISOR_set_timer_op(u64 timeout)
Jeremy Fitzhardinge 2007-07-17 305 {
Jeremy Fitzhardinge 2007-07-17 306 unsigned long timeout_hi = (unsigned long)(timeout>>32);
Jeremy Fitzhardinge 2007-07-17 307 unsigned long timeout_lo = (unsigned long)timeout;
Jeremy Fitzhardinge 2007-07-17 308 return _hypercall2(long, set_timer_op, timeout_lo, timeout_hi);
Jeremy Fitzhardinge 2007-07-17 309 }
Jeremy Fitzhardinge 2007-07-17 310
Jeremy Fitzhardinge 2007-07-17 311 static inline int
Liu, Jinsong 2012-06-07 312 HYPERVISOR_mca(struct xen_mc *mc_op)
Liu, Jinsong 2012-06-07 313 {
Liu, Jinsong 2012-06-07 314 mc_op->interface_version = XEN_MCA_INTERFACE_VERSION;
Liu, Jinsong 2012-06-07 315 return _hypercall1(int, mca, mc_op);
Liu, Jinsong 2012-06-07 316 }
Liu, Jinsong 2012-06-07 317
Liu, Jinsong 2012-06-07 318 static inline int
Stefano Stabellini 2015-11-23 319 HYPERVISOR_platform_op(struct xen_platform_op *op)
Jeremy Fitzhardinge 2011-09-23 320 {
Stefano Stabellini 2015-11-23 321 op->interface_version = XENPF_INTERFACE_VERSION;
Stefano Stabellini 2015-11-23 322 return _hypercall1(int, platform_op, op);
Jeremy Fitzhardinge 2011-09-23 323 }
Jeremy Fitzhardinge 2011-09-23 324
Jeremy Fitzhardinge 2011-09-23 325 static inline int
Jeremy Fitzhardinge 2007-07-17 326 HYPERVISOR_set_debugreg(int reg, unsigned long value)
Jeremy Fitzhardinge 2007-07-17 327 {
Jeremy Fitzhardinge 2007-07-17 328 return _hypercall2(int, set_debugreg, reg, value);
Jeremy Fitzhardinge 2007-07-17 329 }
Jeremy Fitzhardinge 2007-07-17 330
Jeremy Fitzhardinge 2007-07-17 331 static inline unsigned long
Jeremy Fitzhardinge 2007-07-17 332 HYPERVISOR_get_debugreg(int reg)
Jeremy Fitzhardinge 2007-07-17 333 {
Jeremy Fitzhardinge 2007-07-17 334 return _hypercall1(unsigned long, get_debugreg, reg);
Jeremy Fitzhardinge 2007-07-17 335 }
Jeremy Fitzhardinge 2007-07-17 336
Jeremy Fitzhardinge 2007-07-17 337 static inline int
Jeremy Fitzhardinge 2007-07-17 338 HYPERVISOR_update_descriptor(u64 ma, u64 desc)
Jeremy Fitzhardinge 2007-07-17 339 {
Jan Beulich 2009-03-12 340 if (sizeof(u64) == sizeof(long))
Jan Beulich 2009-03-12 341 return _hypercall2(int, update_descriptor, ma, desc);
Jeremy Fitzhardinge 2007-07-17 342 return _hypercall4(int, update_descriptor, ma, ma>>32, desc, desc>>32);
Jeremy Fitzhardinge 2007-07-17 343 }
Jeremy Fitzhardinge 2007-07-17 344
Juergen Gross 2015-09-04 345 static inline long
Jeremy Fitzhardinge 2007-07-17 346 HYPERVISOR_memory_op(unsigned int cmd, void *arg)
Jeremy Fitzhardinge 2007-07-17 347 {
Juergen Gross 2015-09-04 348 return _hypercall2(long, memory_op, cmd, arg);
Jeremy Fitzhardinge 2007-07-17 349 }
Jeremy Fitzhardinge 2007-07-17 350
Jeremy Fitzhardinge 2007-07-17 351 static inline int
Ian Campbell 2014-04-17 352 HYPERVISOR_multicall(void *call_list, uint32_t nr_calls)
Jeremy Fitzhardinge 2007-07-17 353 {
Jeremy Fitzhardinge 2007-07-17 354 return _hypercall2(int, multicall, call_list, nr_calls);
Jeremy Fitzhardinge 2007-07-17 355 }
Jeremy Fitzhardinge 2007-07-17 356
Jeremy Fitzhardinge 2007-07-17 357 static inline int
Jeremy Fitzhardinge 2007-07-17 358 HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val,
Jeremy Fitzhardinge 2007-07-17 359 unsigned long flags)
Jeremy Fitzhardinge 2007-07-17 360 {
Jeremy Fitzhardinge 2008-07-08 361 if (sizeof(new_val) == sizeof(long))
Jeremy Fitzhardinge 2008-07-08 362 return _hypercall3(int, update_va_mapping, va,
Jeremy Fitzhardinge 2008-07-08 363 new_val.pte, flags);
Jeremy Fitzhardinge 2008-07-08 364 else
Jeremy Fitzhardinge 2007-07-17 @365 return _hypercall4(int, update_va_mapping, va,
Jeremy Fitzhardinge 2008-07-08 @366 new_val.pte, new_val.pte >> 32, flags);
Jeremy Fitzhardinge 2007-07-17 367 }
Jan Beulich 2012-10-19 368 extern int __must_check xen_event_channel_op_compat(int, void *);
Jeremy Fitzhardinge 2007-07-17 369
Jeremy Fitzhardinge 2007-07-17 370 static inline int
Jeremy Fitzhardinge 2007-07-17 371 HYPERVISOR_event_channel_op(int cmd, void *arg)
Jeremy Fitzhardinge 2007-07-17 372 {
Jeremy Fitzhardinge 2007-07-17 373 int rc = _hypercall2(int, event_channel_op, cmd, arg);
Jan Beulich 2012-10-19 374 if (unlikely(rc == -ENOSYS))
Jan Beulich 2012-10-19 375 rc = xen_event_channel_op_compat(cmd, arg);
Jeremy Fitzhardinge 2007-07-17 376 return rc;
Jeremy Fitzhardinge 2007-07-17 377 }
Jeremy Fitzhardinge 2007-07-17 378
Jeremy Fitzhardinge 2007-07-17 379 static inline int
Jeremy Fitzhardinge 2007-07-17 380 HYPERVISOR_xen_version(int cmd, void *arg)
Jeremy Fitzhardinge 2007-07-17 381 {
Jeremy Fitzhardinge 2007-07-17 382 return _hypercall2(int, xen_version, cmd, arg);
Jeremy Fitzhardinge 2007-07-17 383 }
Jeremy Fitzhardinge 2007-07-17 384
Jeremy Fitzhardinge 2007-07-17 385 static inline int
Jeremy Fitzhardinge 2007-07-17 386 HYPERVISOR_console_io(int cmd, int count, char *str)
Jeremy Fitzhardinge 2007-07-17 387 {
Jeremy Fitzhardinge 2007-07-17 388 return _hypercall3(int, console_io, cmd, count, str);
Jeremy Fitzhardinge 2007-07-17 389 }
Jeremy Fitzhardinge 2007-07-17 390
Jan Beulich 2013-03-12 391 extern int __must_check xen_physdev_op_compat(int, void *);
Jan Beulich 2012-10-19 392
Jeremy Fitzhardinge 2007-07-17 393 static inline int
Jeremy Fitzhardinge 2007-07-17 394 HYPERVISOR_physdev_op(int cmd, void *arg)
Jeremy Fitzhardinge 2007-07-17 395 {
Jeremy Fitzhardinge 2007-07-17 396 int rc = _hypercall2(int, physdev_op, cmd, arg);
Jan Beulich 2012-10-19 397 if (unlikely(rc == -ENOSYS))
Jan Beulich 2013-03-12 398 rc = xen_physdev_op_compat(cmd, arg);
Jeremy Fitzhardinge 2007-07-17 399 return rc;
Jeremy Fitzhardinge 2007-07-17 400 }
Jeremy Fitzhardinge 2007-07-17 401
Jeremy Fitzhardinge 2007-07-17 402 static inline int
Jeremy Fitzhardinge 2007-07-17 403 HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
Jeremy Fitzhardinge 2007-07-17 404 {
Jeremy Fitzhardinge 2007-07-17 405 return _hypercall3(int, grant_table_op, cmd, uop, count);
Jeremy Fitzhardinge 2007-07-17 406 }
Jeremy Fitzhardinge 2007-07-17 407
Jeremy Fitzhardinge 2007-07-17 408 static inline int
Jeremy Fitzhardinge 2007-07-17 409 HYPERVISOR_update_va_mapping_otherdomain(unsigned long va, pte_t new_val,
Jeremy Fitzhardinge 2007-07-17 410 unsigned long flags, domid_t domid)
Jeremy Fitzhardinge 2007-07-17 411 {
Jeremy Fitzhardinge 2008-07-08 412 if (sizeof(new_val) == sizeof(long))
Jeremy Fitzhardinge 2008-07-08 413 return _hypercall4(int, update_va_mapping_otherdomain, va,
Jeremy Fitzhardinge 2008-07-08 414 new_val.pte, flags, domid);
Jeremy Fitzhardinge 2008-07-08 415 else
Jeremy Fitzhardinge 2007-07-17 @416 return _hypercall5(int, update_va_mapping_otherdomain, va,
Jeremy Fitzhardinge 2008-07-08 @417 new_val.pte, new_val.pte >> 32,
Jeremy Fitzhardinge 2008-07-08 418 flags, domid);
Jeremy Fitzhardinge 2007-07-17 419 }
Jeremy Fitzhardinge 2007-07-17 420
introduced by commit
xen: fix 64-bit hypercall variants
href="/cdn-cgi/l/email-protection#82a4eef6b9e8e7f0e7effbc2e5ededf2acedf0e5a4e5f6b9"><[email protected]>
/email-protection#052369713e686c6b626a45606971602b6d702362713e"><[email protected]>
Open Source Technology Center
build-all">https://lists.01.org/pipermail/kbuild-all Intel Corporation

Attachments:

(No filename) (30.09 kB)
.config.gz (61.24 kB)
Download all attachments