From: Liam Merwick <Liam.Merwick@oracle.com>
The x86/HVM direct boot ABI permits Qemu to be able to boot directly
into the uncompressed Linux kernel binary without the need to run firmware.
https://xenbits.xen.org/docs/unstable/misc/pvh.html
This commit adds the header file that defines the start_info struct
that needs to be populated in order to use this ABI.
Signed-off-by: Maran Wilson <Maran.Wilson@oracle.com>
Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <Konrad.Wilk@oracle.com>
---
include/hw/xen/start_info.h | 146 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 146 insertions(+)
create mode 100644 include/hw/xen/start_info.h
diff --git a/include/hw/xen/start_info.h b/include/hw/xen/start_info.h
new file mode 100644
index 000000000000..348779eb10cd
--- /dev/null
+++ b/include/hw/xen/start_info.h
@@ -0,0 +1,146 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ * 0 +----------------+
+ * | 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 1. New
+ * | | versions are guaranteed to be backwards-compatible.
+ * 8 +----------------+
+ * | flags | SIF_xxx flags.
+ * 12 +----------------+
+ * | nr_modules | Number of modules passed to the kernel.
+ * 16 +----------------+
+ * | modlist_paddr | Physical address of an array of modules
+ * | | (layout of the structure below).
+ * 24 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 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:
+ *
+ * 0 +----------------+
+ * | paddr | Physical address of the module.
+ * 8 +----------------+
+ * | size | Size of the module in bytes.
+ * 16 +----------------+
+ * | cmdline_paddr | Physical address of the command line,
+ * | | a zero-terminated ASCII string.
+ * 24 +----------------+
+ * | 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
+
+/*
+ * C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout is above, this is just a way to
+ * represent the layout described there using C types.
+ */
+struct hvm_start_info {
+ uint32_t magic; /* Contains the magic value 0x336ec578 */
+ /* ("xEn3" with the 0x80 bit of the "E" set).*/
+ uint32_t version; /* Version of this structure. */
+ uint32_t flags; /* SIF_xxx flags. */
+ uint32_t nr_modules; /* Number of modules passed to the kernel. */
+ uint64_t modlist_paddr; /* Physical address of an array of */
+ /* hvm_modlist_entry. */
+ 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 {
+ uint64_t paddr; /* Physical address of the module. */
+ uint64_t size; /* Size of the module in bytes. */
+ uint64_t cmdline_paddr; /* Physical address of the command line. */
+ 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__ */
--
1.8.3.1
On Wed, Dec 05, 2018 at 10:37:24PM +0000, Liam Merwick wrote: > From: Liam Merwick <Liam.Merwick@oracle.com> > > The x86/HVM direct boot ABI permits Qemu to be able to boot directly > into the uncompressed Linux kernel binary without the need to run firmware. > > https://xenbits.xen.org/docs/unstable/misc/pvh.html > > This commit adds the header file that defines the start_info struct > that needs to be populated in order to use this ABI. > > Signed-off-by: Maran Wilson <Maran.Wilson@oracle.com> > Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com> > Reviewed-by: Konrad Rzeszutek Wilk <Konrad.Wilk@oracle.com> > --- > include/hw/xen/start_info.h | 146 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 146 insertions(+) > create mode 100644 include/hw/xen/start_info.h Does it make sense to bring in Linux include/xen/interface/hvm/start_info.h via QEMU's include/standard-headers/? QEMU has a script in scripts/update-linux-header.sh for syncing Linux headers into include/standard-headers/. This makes it easy to keep Linux header files up-to-date. We basically treat files in include/standard-headers/ as auto-generated. If you define start_info.h yourself without using include/standard-headers/, then it won't be synced with Linux.
On 11/12/2018 14:01, Stefan Hajnoczi wrote: > On Wed, Dec 05, 2018 at 10:37:24PM +0000, Liam Merwick wrote: >> From: Liam Merwick <Liam.Merwick@oracle.com> >> >> The x86/HVM direct boot ABI permits Qemu to be able to boot directly >> into the uncompressed Linux kernel binary without the need to run firmware. >> >> https://xenbits.xen.org/docs/unstable/misc/pvh.html >> >> This commit adds the header file that defines the start_info struct >> that needs to be populated in order to use this ABI. >> >> Signed-off-by: Maran Wilson <Maran.Wilson@oracle.com> >> Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com> >> Reviewed-by: Konrad Rzeszutek Wilk <Konrad.Wilk@oracle.com> >> --- >> include/hw/xen/start_info.h | 146 ++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 146 insertions(+) >> create mode 100644 include/hw/xen/start_info.h > > Does it make sense to bring in Linux > include/xen/interface/hvm/start_info.h via QEMU's > include/standard-headers/? > > QEMU has a script in scripts/update-linux-header.sh for syncing Linux > headers into include/standard-headers/. This makes it easy to keep > Linux header files up-to-date. We basically treat files in > include/standard-headers/ as auto-generated. > > If you define start_info.h yourself without using > include/standard-headers/, then it won't be synced with Linux. > That does seem better. I will make that change. One a related note, I'm trying to fix the mingw compilation errors [1] in this series also. I can fix the format issues with PRIx64, etc but I can't seem to find an include file to provide a declaration of mmap() et. al. - has this been resolved before? A pointer to something similar to investigate would be very welcome. Regards, Liam [1] http://patchew.org/logs/1544049446-6359-1-git-send-email-liam.merwick@oracle.com/testing.docker-mingw@fedora/?type=message
On Tue, Dec 11, 2018 at 02:57:29PM +0000, Liam Merwick wrote: > > > On 11/12/2018 14:01, Stefan Hajnoczi wrote: > > On Wed, Dec 05, 2018 at 10:37:24PM +0000, Liam Merwick wrote: > > > From: Liam Merwick <Liam.Merwick@oracle.com> > > > > > > The x86/HVM direct boot ABI permits Qemu to be able to boot directly > > > into the uncompressed Linux kernel binary without the need to run firmware. > > > > > > https://xenbits.xen.org/docs/unstable/misc/pvh.html > > > > > > This commit adds the header file that defines the start_info struct > > > that needs to be populated in order to use this ABI. > > > > > > Signed-off-by: Maran Wilson <Maran.Wilson@oracle.com> > > > Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com> > > > Reviewed-by: Konrad Rzeszutek Wilk <Konrad.Wilk@oracle.com> > > > --- > > > include/hw/xen/start_info.h | 146 ++++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 146 insertions(+) > > > create mode 100644 include/hw/xen/start_info.h > > > > Does it make sense to bring in Linux > > include/xen/interface/hvm/start_info.h via QEMU's > > include/standard-headers/? > > > > QEMU has a script in scripts/update-linux-header.sh for syncing Linux > > headers into include/standard-headers/. This makes it easy to keep > > Linux header files up-to-date. We basically treat files in > > include/standard-headers/ as auto-generated. > > > > If you define start_info.h yourself without using > > include/standard-headers/, then it won't be synced with Linux. > > > > That does seem better. I will make that change. > > One a related note, I'm trying to fix the mingw compilation errors [1] in > this series also. I can fix the format issues with PRIx64, etc but I can't > seem to find an include file to provide a declaration of mmap() et. al. - > has this been resolved before? A pointer to something similar to investigate > would be very welcome. There is no mmap() on mingw, so you'll have to make sure that code is conditionally compiled with #ifndef WIN32 where appropriate. > [1] http://patchew.org/logs/1544049446-6359-1-git-send-email-liam.merwick@oracle.com/testing.docker-mingw@fedora/?type=message > Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 11/12/2018 14:57, Liam Merwick wrote: > On 11/12/2018 14:01, Stefan Hajnoczi wrote: >> On Wed, Dec 05, 2018 at 10:37:24PM +0000, Liam Merwick wrote: >>> From: Liam Merwick <Liam.Merwick@oracle.com> >>> >>> The x86/HVM direct boot ABI permits Qemu to be able to boot directly >>> into the uncompressed Linux kernel binary without the need to run >>> firmware. >>> >>> https://xenbits.xen.org/docs/unstable/misc/pvh.html >>> >>> This commit adds the header file that defines the start_info struct >>> that needs to be populated in order to use this ABI. >>> >>> Signed-off-by: Maran Wilson <Maran.Wilson@oracle.com> >>> Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com> >>> Reviewed-by: Konrad Rzeszutek Wilk <Konrad.Wilk@oracle.com> >>> --- >>> include/hw/xen/start_info.h | 146 >>> ++++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 146 insertions(+) >>> create mode 100644 include/hw/xen/start_info.h >> >> Does it make sense to bring in Linux >> include/xen/interface/hvm/start_info.h via QEMU's >> include/standard-headers/? >> >> QEMU has a script in scripts/update-linux-header.sh for syncing Linux >> headers into include/standard-headers/. This makes it easy to keep >> Linux header files up-to-date. We basically treat files in >> include/standard-headers/ as auto-generated. >> >> If you define start_info.h yourself without using >> include/standard-headers/, then it won't be synced with Linux. >> > > That does seem better. I will make that change. When attempting to implement this, I found the canonical copy of this header file is actually in Xen and the Linux copy is kept in sync with that. Also, 'make headers_install' doesn't install those Xen headers. Instead I updated the commit comment to mention the canonical copy location. This file isn't expected to change much so I think keeping it in sync in future shouldn't be onerous. Regards, Liam
© 2016 - 2026 Red Hat, Inc.