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

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 (2): xen/pvh: Add memory map pointer to hvm_start_info struct KVM: x86: Allow Qemu/KVM to use PVH e

[RFC PATCH v3 1/2] 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. ---

[RFC PATCH v3 2/2] 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

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

On 5/18/2018 4:31 AM, Paolo Bonzini wrote: On 16/05/2018 22:27, Maran Wilson wrote: Friendly ping. I am hopeful one of the x86 and/or KVM maintainers has a few cycles to spare to look this over. And thanks to everyone who has helped thus far by providing valuable feedback and reviewing

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

On 12/6/2018 1:21 PM, Paolo Bonzini wrote: On 06/12/18 07:02, 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

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

On 12/12/2018 12:39 PM, Borislav Petkov wrote: On Tue, Dec 11, 2018 at 11:29:21AM -0800, Maran Wilson wrote: Is your question about what options you need to provide to Qemu? Or is your question about the SW implementation choices? Assuming the former... Yeah, that's what I wanted to know

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

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

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

CONFIG_XEN. Signed-off-by: Maran Wilson Reviewed-by: Juergen Gross --- 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 8689e794a43c

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

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 Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Juergen Gross --- MAINTAINERS

[PATCH v9 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 Reviewed-by: Juergen Gross --- arch/x86

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

. 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 Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Juergen Gross --- arch/x86

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

-by: Maran Wilson Reviewed-by: Juergen Gross --- 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

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

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 Reviewed-by: Juergen Gross --- arch/x86/platform/pvh/enlighten.c | 29

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

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 Suggested-by: Konrad Rzeszutek Wilk Suggested

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

On 12/11/2018 5:18 AM, Borislav Petkov wrote: On Mon, Dec 10, 2018 at 11:05:34AM -0800, 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

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

On 12/7/2018 7:14 AM, Paolo Bonzini wrote: On 07/12/18 14:58, Juergen Gross wrote: On 07/12/2018 14:52, Paolo Bonzini wrote: On 07/12/18 14:50, Juergen Gross wrote: The PVH boot entry is in the same bzImage binary as the normal one. Its just another entry, similar to the Xen PV boot entry. So

<    1   2