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
On 11/29/2017 12:21 AM, Juergen Gross wrote:
On 28/11/17 20:34, 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
On 11/29/2017 12:59 AM, Paolo Bonzini wrote:
On 28/11/2017 20:34, 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
On 11/29/2017 6:44 AM, Paolo Bonzini wrote:
I actually like this patch, except that I'd get the e820 memory map from
fw_cfg (see the first part of
https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820
inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the
second
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
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.
---
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
CONFIG_XEN to start KVM guests via the
PVH entry point. If the latter, any suggestions for which common files or
directories I can move this stuff to?
Maran Wilson (2):
xen/pvh: Add memory map pointer to hvm_start_info struct
KVM: x86: Allow Qemu/KVM to use PVH entry point
arch/x86/xen
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 efficiently pass information about the memory
map to the guest.
That way Xen PVH guests would not be forced to use a hypercall
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
hanks,
-Maran
On 12/1/2017 12:08 AM, Paolo Bonzini wrote:
On 30/11/2017 19:23, Maran Wilson wrote:
Are you saying the Linux PVH entry code (such as init_pvh_bootparams())
should use the fw_cfg interface to read the e820 memory map data and put
it into the zeropage? Basically, keeping the
Thanks for taking a look Jan. More below...
On 12/8/2017 12:49 AM, Jan Beulich wrote:
On 07.12.17 at 23:45, 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
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-
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
On 4/18/2018 1:11 AM, Linus Walleij wrote:
I wonder why I am starting to get CCed on Xen patches all of a sudden.
I happened to run into Jürgen at a conference only last weekend, but
I still don't know anything whatsoever about Xen or how it works.
If get_maintainer.pl has started to return my
-by: Maran Wilson <maran.wil...@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..80cfbd
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):
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.wil...@oracle.com>
---
arch/x86/
CONFIG_XEN.
Signed-off-by: Maran Wilson <maran.wil...@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
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.wil...@oracle.com>
---
MAINTAINERS | 1 +
arch/x86/
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.wil...@oracle.com>
---
arch/x86
. 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.wil...@oracle.com>
---
arch/x86/pvh.c
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.wil...@oracle.com>
---
arch/x86/pvh.c
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
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.wil...@oracle.com>
---
ar
. 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.wil...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <
-by: Maran Wilson <maran.wil...@oracle.com>
---
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..50af9e
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.wil...@oracle.com>
Suggested-by:
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.wil...@oracle.com>
Reviewed-by: Juergen Gross <jgr...@suse.com>
-
CONFIG_XEN.
Signed-off-by: Maran Wilson <maran.wil...@oracle.com>
---
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 27fede
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.wil...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
n.
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_XE
CONFIG_XEN.
Signed-off-by: Maran Wilson <maran.wil...@oracle.com>
---
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 d234cc
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.wil...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
-by: Maran Wilson <maran.wil...@oracle.com>
---
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..50af9e
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.wil...@oracle.com>
Suggested-by:
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.wil...@oracle.com>
Reviewed-by: Juergen Gross <jgr...@suse.com>
-
. 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.wil...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <
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.wil...@oracle.com>
---
ar
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
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.
Signed-off-by: Maran Wilson <maran.wil...@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
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.wil...@oracle.com>
---
ar
-by: Maran Wilson <maran.wil...@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..d491f2
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.wil...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
. 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.wil...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <
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.wil...@oracle.com>
Reviewed-by: Juergen Gross <jgr...@suse.com>
-
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.wil...@oracle.com>
Suggested-by:
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
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
On 2/28/2018 11:41 PM, Jan Beulich wrote:
Juergen Gross <jgr...@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 i
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
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
---
arch/x86/pvh.c | 28 ++--
arch/x86/xen
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
---
arch/x86/pvh.c | 1
CONFIG_XEN.
Signed-off-by: Maran Wilson
---
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
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
---
MAINTAINERS | 1 +
arch/x86/Kbuild | 3 +++
arch/x86/{xen/xen
. 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
---
arch/x86/pvh.c | 28
arch/x86/xen
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):
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
---
arch/x86/Kbuild | 4 ++--
arch/x86/pvh.c
-by: Maran Wilson
---
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
On 2/28/2018 11:41 PM, Jan Beulich wrote:
Juergen Gross 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 wa
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
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
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
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.
Signed-off-by: Maran Wilson
---
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
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
---
arch/x86/platform/pvh/enlighten.c | 5
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 | 28
. 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
-by: Maran Wilson
---
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
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
---
MAINTAINERS| 1 +
arch/x86
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
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
On 4/18/2018 1:11 AM, Linus Walleij wrote:
I wonder why I am starting to get CCed on Xen patches all of a sudden.
I happened to run into Jürgen at a conference only last weekend, but
I still don't know anything whatsoever about Xen or how it works.
If get_maintainer.pl has started to return my
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-
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
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_XEN.
Signed-off-by: Maran Wilson
---
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
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
---
MAINTAINERS| 1 +
arch/x86
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 | 28
. 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
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
---
arch/x86/platform/pvh/enlighten.c | 5
-by: Maran Wilson
---
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
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
n.
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_XE
CONFIG_XEN.
Signed-off-by: Maran Wilson
---
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 d234cca296db..8511d419e39f 100644
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
---
MAINTAINERS| 1 +
arch/x86
. 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
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
---
arch/x86/platform/pvh/enlighten.c | 5
-by: Maran Wilson
---
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
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
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
CONFIG_XEN to start KVM guests via the
PVH entry point. If the latter, any suggestions for which common files or
directories I can move this stuff to?
Maran Wilson (2):
xen/pvh: Add memory map pointer to hvm_start_info struct
KVM: x86: Allow Qemu/KVM to use PVH entry point
arch/x86/xen
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 efficiently pass information about the memory
map to the guest.
That way Xen PVH guests would not be forced to use a hypercall
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
hanks,
-Maran
On 12/1/2017 12:08 AM, Paolo Bonzini wrote:
On 30/11/2017 19:23, Maran Wilson wrote:
Are you saying the Linux PVH entry code (such as init_pvh_bootparams())
should use the fw_cfg interface to read the e820 memory map data and put
it into the zeropage? Basically, keeping the
On 11/29/2017 12:59 AM, Paolo Bonzini wrote:
On 28/11/2017 20:34, 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
On 11/29/2017 12:21 AM, Juergen Gross wrote:
On 28/11/17 20:34, 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
On 11/29/2017 6:44 AM, Paolo Bonzini wrote:
I actually like this patch, except that I'd get the e820 memory map from
fw_cfg (see the first part of
https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820
inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the
second
Thanks for taking a look Jan. More below...
On 12/8/2017 12:49 AM, Jan Beulich wrote:
On 07.12.17 at 23:45, 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
1 - 100 of 116 matches
Mail list logo