* [PATCH v2 00/18] xen: add pvh guest support
@ 2018-10-09 11:02 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:02 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
This patch series adds support for booting Linux as PVH guest.
Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
platform grub is booted as a standalone image directly by Xen.
For booting Linux kernel it is using the standard linux kernel
loader. The only modification of the linux loader is to pass the
ACPI RSDP address via boot parameters to the kernel, as that table
might not be located at the usual physical address just below 1MB.
As the related Linux kernel patches are not yet accepted please
wait for this to happen before applying the series. This Linux kernel
series is available under:
https://lists.xen.org/archives/html/xen-devel/2018-10/msg00776.html
Changes in V2:
- extend linux boot protocol version 2.14 to report back the protocol
version supported by grub2 (needed as there are grub2 downstream
variants in some distros which clobber data after the setup_header)
- split former patch 4 into 10 patches
- fix memmap handling for >4GB of memory
- added new patch from Hans (thanks for that one)
- addressed most of Daniel's comments (see individual patches)
Hans van Kranenburg (1):
grub-module-verifier: Ignore all_video for xenpvh
Juergen Gross (17):
xen: add some xen headers
loader/linux: support passing rsdp address via boot params
xen: carve out grant tab initialization into dedicated function
xen: prepare common code for Xen PVH support
xen: add some dummy headers for PVH mode
xen: rearrange xen/init.c to prepare it for Xen PVH mode
xen: add PVH specific defines to offset.h
xen: add basic hooks for PVH in current code
xen: add PVH boot entry code
xen: setup hypercall page for PVH
xen: get memory map from hypervisor for PVH
xen: setup Xen specific data for PVH
xen: init memory regions for PVH
xenpvh: add build runes for grub-core
xenpvh: support building a standalone image
xenpvh: support grub-install for xenpvh
xenpvh: add support to configure
configure.ac | 3 +
gentpl.py | 4 +-
grub-core/Makefile.am | 12 +
grub-core/Makefile.core.def | 35 ++
grub-core/kern/i386/tsc.c | 2 +-
grub-core/kern/i386/xen/pvh.c | 346 ++++++++++++++++++
grub-core/kern/i386/xen/startup_pvh.S | 79 ++++
grub-core/kern/xen/init.c | 101 ++++--
grub-core/loader/i386/linux.c | 9 +
include/grub/i386/linux.h | 5 +-
include/grub/i386/pc/int.h | 3 +
include/grub/i386/tsc.h | 2 +-
include/grub/i386/xen/hypercall.h | 5 +-
include/grub/i386/xenpvh/boot.h | 1 +
include/grub/i386/xenpvh/console.h | 1 +
include/grub/i386/xenpvh/int.h | 1 +
include/grub/i386/xenpvh/kernel.h | 30 ++
include/grub/i386/xenpvh/memory.h | 1 +
include/grub/i386/xenpvh/time.h | 1 +
include/grub/kernel.h | 4 +-
include/grub/offsets.h | 21 +-
include/grub/util/install.h | 1 +
include/grub/util/mkimage.h | 3 +-
include/grub/xen.h | 6 +
include/xen/hvm/hvm_op.h | 296 +++++++++++++++
include/xen/hvm/params.h | 284 +++++++++++++++
include/xen/hvm/start_info.h | 98 +++++
include/xen/memory.h | 665 ++++++++++++++++++++++++++++++++++
include/xen/physdev.h | 387 ++++++++++++++++++++
include/xen/trace.h | 339 +++++++++++++++++
include/xen/xen.h | 104 ++++--
util/grub-install-common.c | 1 +
util/grub-install.c | 7 +
util/grub-mkimage32.c | 4 +-
util/grub-mkimage64.c | 4 +-
util/grub-mkimagexx.c | 58 ++-
util/grub-module-verifier.c | 1 +
util/mkimage.c | 23 +-
38 files changed, 2846 insertions(+), 101 deletions(-)
create mode 100644 grub-core/kern/i386/xen/pvh.c
create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
create mode 100644 include/grub/i386/xenpvh/boot.h
create mode 100644 include/grub/i386/xenpvh/console.h
create mode 100644 include/grub/i386/xenpvh/int.h
create mode 100644 include/grub/i386/xenpvh/kernel.h
create mode 100644 include/grub/i386/xenpvh/memory.h
create mode 100644 include/grub/i386/xenpvh/time.h
create mode 100644 include/xen/hvm/hvm_op.h
create mode 100644 include/xen/hvm/params.h
create mode 100644 include/xen/hvm/start_info.h
create mode 100644 include/xen/memory.h
create mode 100644 include/xen/physdev.h
create mode 100644 include/xen/trace.h
--
2.16.4
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 01/18] xen: add some xen headers
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
In order to support grub2 in Xen PVH environment some additional Xen
headers are needed as grub2 will be started in PVH mode requiring to
use several HVM hypercalls and structures.
Add the needed headers from Xen 4.10 being the first Xen version with
full (not only experimental) PVH guest support.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: update commit message (Daniel Kiper)
---
include/xen/hvm/hvm_op.h | 296 +++++++++++++++++++
include/xen/hvm/params.h | 284 ++++++++++++++++++
include/xen/hvm/start_info.h | 98 +++++++
include/xen/memory.h | 665 +++++++++++++++++++++++++++++++++++++++++++
include/xen/physdev.h | 387 +++++++++++++++++++++++++
include/xen/trace.h | 339 ++++++++++++++++++++++
include/xen/xen.h | 104 +++++--
7 files changed, 2142 insertions(+), 31 deletions(-)
create mode 100644 include/xen/hvm/hvm_op.h
create mode 100644 include/xen/hvm/params.h
create mode 100644 include/xen/hvm/start_info.h
create mode 100644 include/xen/memory.h
create mode 100644 include/xen/physdev.h
create mode 100644 include/xen/trace.h
diff --git a/include/xen/hvm/hvm_op.h b/include/xen/hvm/hvm_op.h
new file mode 100644
index 000000000..0bdafdf59
--- /dev/null
+++ b/include/xen/hvm/hvm_op.h
@@ -0,0 +1,296 @@
+/*
+ * 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) 2007, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_HVM_HVM_OP_H__
+#define __XEN_PUBLIC_HVM_HVM_OP_H__
+
+#include "../xen.h"
+#include "../trace.h"
+#include "../event_channel.h"
+
+/* Get/set subcommands: extra argument == pointer to xen_hvm_param struct. */
+#define HVMOP_set_param 0
+#define HVMOP_get_param 1
+struct xen_hvm_param {
+ domid_t domid; /* IN */
+ uint32_t index; /* IN */
+ uint64_t value; /* IN/OUT */
+};
+typedef struct xen_hvm_param xen_hvm_param_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_param_t);
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040900
+
+/* Set the logical level of one of a domain's PCI INTx wires. */
+#define HVMOP_set_pci_intx_level 2
+struct xen_hvm_set_pci_intx_level {
+ /* Domain to be updated. */
+ domid_t domid;
+ /* PCI INTx identification in PCI topology (domain:bus:device:intx). */
+ uint8_t domain, bus, device, intx;
+ /* Assertion level (0 = unasserted, 1 = asserted). */
+ uint8_t level;
+};
+typedef struct xen_hvm_set_pci_intx_level xen_hvm_set_pci_intx_level_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_pci_intx_level_t);
+
+/* Set the logical level of one of a domain's ISA IRQ wires. */
+#define HVMOP_set_isa_irq_level 3
+struct xen_hvm_set_isa_irq_level {
+ /* Domain to be updated. */
+ domid_t domid;
+ /* ISA device identification, by ISA IRQ (0-15). */
+ uint8_t isa_irq;
+ /* Assertion level (0 = unasserted, 1 = asserted). */
+ uint8_t level;
+};
+typedef struct xen_hvm_set_isa_irq_level xen_hvm_set_isa_irq_level_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_isa_irq_level_t);
+
+#define HVMOP_set_pci_link_route 4
+struct xen_hvm_set_pci_link_route {
+ /* Domain to be updated. */
+ domid_t domid;
+ /* PCI link identifier (0-3). */
+ uint8_t link;
+ /* ISA IRQ (1-15), or 0 (disable link). */
+ uint8_t isa_irq;
+};
+typedef struct xen_hvm_set_pci_link_route xen_hvm_set_pci_link_route_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t);
+
+#endif /* __XEN_INTERFACE_VERSION__ < 0x00040900 */
+
+/* Flushes all VCPU TLBs: @arg must be NULL. */
+#define HVMOP_flush_tlbs 5
+
+typedef enum {
+ HVMMEM_ram_rw, /* Normal read/write guest RAM */
+ HVMMEM_ram_ro, /* Read-only; writes are discarded */
+ HVMMEM_mmio_dm, /* Reads and write go to the device model */
+#if __XEN_INTERFACE_VERSION__ < 0x00040700
+ HVMMEM_mmio_write_dm, /* Read-only; writes go to the device model */
+#else
+ HVMMEM_unused, /* Placeholder; setting memory to this type
+ will fail for code after 4.7.0 */
+#endif
+ HVMMEM_ioreq_server /* Memory type claimed by an ioreq server; type
+ changes to this value are only allowed after
+ an ioreq server has claimed its ownership.
+ Only pages with HVMMEM_ram_rw are allowed to
+ change to this type; conversely, pages with
+ this type are only allowed to be changed back
+ to HVMMEM_ram_rw. */
+} hvmmem_type_t;
+
+/* Hint from PV drivers for pagetable destruction. */
+#define HVMOP_pagetable_dying 9
+struct xen_hvm_pagetable_dying {
+ /* Domain with a pagetable about to be destroyed. */
+ domid_t domid;
+ uint16_t pad[3]; /* align next field on 8-byte boundary */
+ /* guest physical address of the toplevel pagetable dying */
+ uint64_t gpa;
+};
+typedef struct xen_hvm_pagetable_dying xen_hvm_pagetable_dying_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_pagetable_dying_t);
+
+/* Get the current Xen time, in nanoseconds since system boot. */
+#define HVMOP_get_time 10
+struct xen_hvm_get_time {
+ uint64_t now; /* OUT */
+};
+typedef struct xen_hvm_get_time xen_hvm_get_time_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_get_time_t);
+
+#define HVMOP_xentrace 11
+struct xen_hvm_xentrace {
+ uint16_t event, extra_bytes;
+ uint8_t extra[TRACE_EXTRA_MAX * sizeof(uint32_t)];
+};
+typedef struct xen_hvm_xentrace xen_hvm_xentrace_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_xentrace_t);
+
+/* Following tools-only interfaces may change in future. */
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+/* Deprecated by XENMEM_access_op_set_access */
+#define HVMOP_set_mem_access 12
+
+/* Deprecated by XENMEM_access_op_get_access */
+#define HVMOP_get_mem_access 13
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
+#define HVMOP_get_mem_type 15
+/* Return hvmmem_type_t for the specified pfn. */
+struct xen_hvm_get_mem_type {
+ /* Domain to be queried. */
+ domid_t domid;
+ /* OUT variable. */
+ uint16_t mem_type;
+ uint16_t pad[2]; /* align next field on 8-byte boundary */
+ /* IN variable. */
+ uint64_t pfn;
+};
+typedef struct xen_hvm_get_mem_type xen_hvm_get_mem_type_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_get_mem_type_t);
+
+/* Following tools-only interfaces may change in future. */
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+/*
+ * Definitions relating to DMOP_create_ioreq_server. (Defined here for
+ * backwards compatibility).
+ */
+
+#define HVM_IOREQSRV_BUFIOREQ_OFF 0
+#define HVM_IOREQSRV_BUFIOREQ_LEGACY 1
+/*
+ * Use this when read_pointer gets updated atomically and
+ * the pointer pair gets read atomically:
+ */
+#define HVM_IOREQSRV_BUFIOREQ_ATOMIC 2
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ * channel upcalls on the specified <vcpu>. If set,
+ * this vector will be used in preference to the
+ * domain global callback via (see
+ * HVM_PARAM_CALLBACK_IRQ).
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_evtchn_upcall_vector {
+ uint32_t vcpu;
+ uint8_t vector;
+};
+typedef struct xen_hvm_evtchn_upcall_vector xen_hvm_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_evtchn_upcall_vector_t);
+
+#endif /* defined(__i386__) || defined(__x86_64__) */
+
+#define HVMOP_guest_request_vm_event 24
+
+/* HVMOP_altp2m: perform altp2m state operations */
+#define HVMOP_altp2m 25
+
+#define HVMOP_ALTP2M_INTERFACE_VERSION 0x00000001
+
+struct xen_hvm_altp2m_domain_state {
+ /* IN or OUT variable on/off */
+ uint8_t state;
+};
+typedef struct xen_hvm_altp2m_domain_state xen_hvm_altp2m_domain_state_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_domain_state_t);
+
+struct xen_hvm_altp2m_vcpu_enable_notify {
+ uint32_t vcpu_id;
+ uint32_t pad;
+ /* #VE info area gfn */
+ uint64_t gfn;
+};
+typedef struct xen_hvm_altp2m_vcpu_enable_notify xen_hvm_altp2m_vcpu_enable_notify_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_vcpu_enable_notify_t);
+
+struct xen_hvm_altp2m_view {
+ /* IN/OUT variable */
+ uint16_t view;
+ /* Create view only: default access type
+ * NOTE: currently ignored */
+ uint16_t hvmmem_default_access; /* xenmem_access_t */
+};
+typedef struct xen_hvm_altp2m_view xen_hvm_altp2m_view_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_view_t);
+
+struct xen_hvm_altp2m_set_mem_access {
+ /* view */
+ uint16_t view;
+ /* Memory type */
+ uint16_t hvmmem_access; /* xenmem_access_t */
+ uint32_t pad;
+ /* gfn */
+ uint64_t gfn;
+};
+typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
+
+struct xen_hvm_altp2m_change_gfn {
+ /* view */
+ uint16_t view;
+ uint16_t pad1;
+ uint32_t pad2;
+ /* old gfn */
+ uint64_t old_gfn;
+ /* new gfn, INVALID_GFN (~0UL) means revert */
+ uint64_t new_gfn;
+};
+typedef struct xen_hvm_altp2m_change_gfn xen_hvm_altp2m_change_gfn_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_change_gfn_t);
+
+struct xen_hvm_altp2m_op {
+ uint32_t version; /* HVMOP_ALTP2M_INTERFACE_VERSION */
+ uint32_t cmd;
+/* Get/set the altp2m state for a domain */
+#define HVMOP_altp2m_get_domain_state 1
+#define HVMOP_altp2m_set_domain_state 2
+/* Set the current VCPU to receive altp2m event notifications */
+#define HVMOP_altp2m_vcpu_enable_notify 3
+/* Create a new view */
+#define HVMOP_altp2m_create_p2m 4
+/* Destroy a view */
+#define HVMOP_altp2m_destroy_p2m 5
+/* Switch view for an entire domain */
+#define HVMOP_altp2m_switch_p2m 6
+/* Notify that a page of memory is to have specific access types */
+#define HVMOP_altp2m_set_mem_access 7
+/* Change a p2m entry to have a different gfn->mfn mapping */
+#define HVMOP_altp2m_change_gfn 8
+ domid_t domain;
+ uint16_t pad1;
+ uint32_t pad2;
+ union {
+ struct xen_hvm_altp2m_domain_state domain_state;
+ struct xen_hvm_altp2m_vcpu_enable_notify enable_notify;
+ struct xen_hvm_altp2m_view view;
+ struct xen_hvm_altp2m_set_mem_access set_mem_access;
+ struct xen_hvm_altp2m_change_gfn change_gfn;
+ uint8_t pad[64];
+ } u;
+};
+typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t);
+
+#endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/hvm/params.h b/include/xen/hvm/params.h
new file mode 100644
index 000000000..2ec2e7c80
--- /dev/null
+++ b/include/xen/hvm/params.h
@@ -0,0 +1,284 @@
+/*
+ * 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) 2007, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_HVM_PARAMS_H__
+#define __XEN_PUBLIC_HVM_PARAMS_H__
+
+#include "hvm_op.h"
+
+/*
+ * Parameter space for HVMOP_{set,get}_param.
+ */
+
+#define HVM_PARAM_CALLBACK_IRQ 0
+#define HVM_PARAM_CALLBACK_IRQ_TYPE_MASK xen_mk_ullong(0xFF00000000000000)
+/*
+ * How should CPU0 event-channel notifications be delivered?
+ *
+ * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI 0
+/*
+ * val[55:0] is a delivery GSI. GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#if defined(__i386__) || defined(__x86_64__)
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
+/*
+ * val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
+ */
+#elif defined(__arm__) || defined(__aarch64__)
+#define HVM_PARAM_CALLBACK_TYPE_PPI 2
+/*
+ * val[55:16] needs to be zero.
+ * val[15:8] is interrupt flag of the PPI used by event-channel:
+ * bit 8: the PPI is edge(1) or level(0) triggered
+ * bit 9: the PPI is active low(1) or high(0)
+ * val[7:0] is a PPI number used by event-channel.
+ * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
+ * the notification is handled by the interrupt controller.
+ */
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK 0xFF00
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
+#endif
+
+/*
+ * These are not used by Xen. They are here for convenience of HVM-guest
+ * xenbus implementations.
+ */
+#define HVM_PARAM_STORE_PFN 1
+#define HVM_PARAM_STORE_EVTCHN 2
+
+#define HVM_PARAM_PAE_ENABLED 4
+
+#define HVM_PARAM_IOREQ_PFN 5
+
+#define HVM_PARAM_BUFIOREQ_PFN 6
+#define HVM_PARAM_BUFIOREQ_EVTCHN 26
+
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * Viridian enlightenments
+ *
+ * (See http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor%20Top%20Level%20Functional%20Specification%20v4.0.docx)
+ *
+ * To expose viridian enlightenments to the guest set this parameter
+ * to the desired feature mask. The base feature set must be present
+ * in any valid feature mask.
+ */
+#define HVM_PARAM_VIRIDIAN 9
+
+/* Base+Freq viridian feature sets:
+ *
+ * - Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL)
+ * - APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR)
+ * - Virtual Processor index MSR (HV_X64_MSR_VP_INDEX)
+ * - Timer frequency MSRs (HV_X64_MSR_TSC_FREQUENCY and
+ * HV_X64_MSR_APIC_FREQUENCY)
+ */
+#define _HVMPV_base_freq 0
+#define HVMPV_base_freq (1 << _HVMPV_base_freq)
+
+/* Feature set modifications */
+
+/* Disable timer frequency MSRs (HV_X64_MSR_TSC_FREQUENCY and
+ * HV_X64_MSR_APIC_FREQUENCY).
+ * This modification restores the viridian feature set to the
+ * original 'base' set exposed in releases prior to Xen 4.4.
+ */
+#define _HVMPV_no_freq 1
+#define HVMPV_no_freq (1 << _HVMPV_no_freq)
+
+/* Enable Partition Time Reference Counter (HV_X64_MSR_TIME_REF_COUNT) */
+#define _HVMPV_time_ref_count 2
+#define HVMPV_time_ref_count (1 << _HVMPV_time_ref_count)
+
+/* Enable Reference TSC Page (HV_X64_MSR_REFERENCE_TSC) */
+#define _HVMPV_reference_tsc 3
+#define HVMPV_reference_tsc (1 << _HVMPV_reference_tsc)
+
+/* Use Hypercall for remote TLB flush */
+#define _HVMPV_hcall_remote_tlb_flush 4
+#define HVMPV_hcall_remote_tlb_flush (1 << _HVMPV_hcall_remote_tlb_flush)
+
+/* Use APIC assist */
+#define _HVMPV_apic_assist 5
+#define HVMPV_apic_assist (1 << _HVMPV_apic_assist)
+
+/* Enable crash MSRs */
+#define _HVMPV_crash_ctl 6
+#define HVMPV_crash_ctl (1 << _HVMPV_crash_ctl)
+
+#define HVMPV_feature_mask \
+ (HVMPV_base_freq | \
+ HVMPV_no_freq | \
+ HVMPV_time_ref_count | \
+ HVMPV_reference_tsc | \
+ HVMPV_hcall_remote_tlb_flush | \
+ HVMPV_apic_assist | \
+ HVMPV_crash_ctl)
+
+#endif
+
+/*
+ * Set mode for virtual timers (currently x86 only):
+ * delay_for_missed_ticks (default):
+ * Do not advance a vcpu's time beyond the correct delivery time for
+ * interrupts that have been missed due to preemption. Deliver missed
+ * interrupts when the vcpu is rescheduled and advance the vcpu's virtual
+ * time stepwise for each one.
+ * no_delay_for_missed_ticks:
+ * As above, missed interrupts are delivered, but guest time always tracks
+ * wallclock (i.e., real) time while doing so.
+ * no_missed_ticks_pending:
+ * No missed interrupts are held pending. Instead, to ensure ticks are
+ * delivered at some non-zero rate, if we detect missed ticks then the
+ * internal tick alarm is not disabled if the VCPU is preempted during the
+ * next tick period.
+ * one_missed_tick_pending:
+ * Missed interrupts are collapsed together and delivered as one 'late tick'.
+ * Guest time always tracks wallclock (i.e., real) time.
+ */
+#define HVM_PARAM_TIMER_MODE 10
+#define HVMPTM_delay_for_missed_ticks 0
+#define HVMPTM_no_delay_for_missed_ticks 1
+#define HVMPTM_no_missed_ticks_pending 2
+#define HVMPTM_one_missed_tick_pending 3
+
+/* Boolean: Enable virtual HPET (high-precision event timer)? (x86-only) */
+#define HVM_PARAM_HPET_ENABLED 11
+
+/* Identity-map page directory used by Intel EPT when CR0.PG=0. */
+#define HVM_PARAM_IDENT_PT 12
+
+/* Device Model domain, defaults to 0. */
+#define HVM_PARAM_DM_DOMAIN 13
+
+/* ACPI S state: currently support S0 and S3 on x86. */
+#define HVM_PARAM_ACPI_S_STATE 14
+
+/* TSS used on Intel when CR0.PE=0. */
+#define HVM_PARAM_VM86_TSS 15
+
+/* Boolean: Enable aligning all periodic vpts to reduce interrupts */
+#define HVM_PARAM_VPT_ALIGN 16
+
+/* Console debug shared memory ring and event channel */
+#define HVM_PARAM_CONSOLE_PFN 17
+#define HVM_PARAM_CONSOLE_EVTCHN 18
+
+/*
+ * Select location of ACPI PM1a and TMR control blocks. Currently two locations
+ * are supported, specified by version 0 or 1 in this parameter:
+ * - 0: default, use the old addresses
+ * PM1A_EVT == 0x1f40; PM1A_CNT == 0x1f44; PM_TMR == 0x1f48
+ * - 1: use the new default qemu addresses
+ * PM1A_EVT == 0xb000; PM1A_CNT == 0xb004; PM_TMR == 0xb008
+ * You can find these address definitions in <hvm/ioreq.h>
+ */
+#define HVM_PARAM_ACPI_IOPORTS_LOCATION 19
+
+/* Deprecated */
+#define HVM_PARAM_MEMORY_EVENT_CR0 20
+#define HVM_PARAM_MEMORY_EVENT_CR3 21
+#define HVM_PARAM_MEMORY_EVENT_CR4 22
+#define HVM_PARAM_MEMORY_EVENT_INT3 23
+#define HVM_PARAM_MEMORY_EVENT_SINGLE_STEP 25
+#define HVM_PARAM_MEMORY_EVENT_MSR 30
+
+/* Boolean: Enable nestedhvm (hvm only) */
+#define HVM_PARAM_NESTEDHVM 24
+
+/* Params for the mem event rings */
+#define HVM_PARAM_PAGING_RING_PFN 27
+#define HVM_PARAM_MONITOR_RING_PFN 28
+#define HVM_PARAM_SHARING_RING_PFN 29
+
+/* SHUTDOWN_* action in case of a triple fault */
+#define HVM_PARAM_TRIPLE_FAULT_REASON 31
+
+#define HVM_PARAM_IOREQ_SERVER_PFN 32
+#define HVM_PARAM_NR_IOREQ_SERVER_PAGES 33
+
+/* Location of the VM Generation ID in guest physical address space. */
+#define HVM_PARAM_VM_GENERATION_ID_ADDR 34
+
+/*
+ * Set mode for altp2m:
+ * disabled: don't activate altp2m (default)
+ * mixed: allow access to all altp2m ops for both in-guest and external tools
+ * external: allow access to external privileged tools only
+ * limited: guest only has limited access (ie. control VMFUNC and #VE)
+ */
+#define HVM_PARAM_ALTP2M 35
+#define XEN_ALTP2M_disabled 0
+#define XEN_ALTP2M_mixed 1
+#define XEN_ALTP2M_external 2
+#define XEN_ALTP2M_limited 3
+
+/*
+ * Size of the x87 FPU FIP/FDP registers that the hypervisor needs to
+ * save/restore. This is a workaround for a hardware limitation that
+ * does not allow the full FIP/FDP and FCS/FDS to be restored.
+ *
+ * Valid values are:
+ *
+ * 8: save/restore 64-bit FIP/FDP and clear FCS/FDS (default if CPU
+ * has FPCSDS feature).
+ *
+ * 4: save/restore 32-bit FIP/FDP, FCS/FDS, and clear upper 32-bits of
+ * FIP/FDP.
+ *
+ * 0: allow hypervisor to choose based on the value of FIP/FDP
+ * (default if CPU does not have FPCSDS).
+ *
+ * If FPCSDS (bit 13 in CPUID leaf 0x7, subleaf 0x0) is set, the CPU
+ * never saves FCS/FDS and this parameter should be left at the
+ * default of 8.
+ */
+#define HVM_PARAM_X87_FIP_WIDTH 36
+
+/*
+ * TSS (and its size) used on Intel when CR0.PE=0. The address occupies
+ * the low 32 bits, while the size is in the high 32 ones.
+ */
+#define HVM_PARAM_VM86_TSS_SIZED 37
+
+/* Enable MCA capabilities. */
+#define HVM_PARAM_MCA_CAP 38
+#define XEN_HVM_MCA_CAP_LMCE (xen_mk_ullong(1) << 0)
+#define XEN_HVM_MCA_CAP_MASK XEN_HVM_MCA_CAP_LMCE
+
+#define HVM_NR_PARAMS 39
+
+#endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
diff --git a/include/xen/hvm/start_info.h b/include/xen/hvm/start_info.h
new file mode 100644
index 000000000..648415976
--- /dev/null
+++ b/include/xen/hvm/start_info.h
@@ -0,0 +1,98 @@
+/*
+ * 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 0. 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 +----------------+
+ *
+ * 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 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.
+ */
+#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. */
+};
+
+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;
+};
+
+#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
diff --git a/include/xen/memory.h b/include/xen/memory.h
new file mode 100644
index 000000000..29386df98
--- /dev/null
+++ b/include/xen/memory.h
@@ -0,0 +1,665 @@
+/******************************************************************************
+ * memory.h
+ *
+ * Memory reservation and information.
+ *
+ * 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) 2005, Keir Fraser <keir@xensource.com>
+ */
+
+#ifndef __XEN_PUBLIC_MEMORY_H__
+#define __XEN_PUBLIC_MEMORY_H__
+
+#include "xen.h"
+#include "physdev.h"
+
+/*
+ * Increase or decrease the specified domain's memory reservation. Returns the
+ * number of extents successfully allocated or freed.
+ * arg == addr of struct xen_memory_reservation.
+ */
+#define XENMEM_increase_reservation 0
+#define XENMEM_decrease_reservation 1
+#define XENMEM_populate_physmap 6
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00030209
+/*
+ * Maximum # bits addressable by the user of the allocated region (e.g., I/O
+ * devices often have a 32-bit limitation even in 64-bit systems). If zero
+ * then the user has no addressing restriction. This field is not used by
+ * XENMEM_decrease_reservation.
+ */
+#define XENMEMF_address_bits(x) (x)
+#define XENMEMF_get_address_bits(x) ((x) & 0xffu)
+/* NUMA node to allocate from. */
+#define XENMEMF_node(x) (((x) + 1) << 8)
+#define XENMEMF_get_node(x) ((((x) >> 8) - 1) & 0xffu)
+/* Flag to populate physmap with populate-on-demand entries */
+#define XENMEMF_populate_on_demand (1<<16)
+/* Flag to request allocation only from the node specified */
+#define XENMEMF_exact_node_request (1<<17)
+#define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request)
+/* Flag to indicate the node specified is virtual node */
+#define XENMEMF_vnode (1<<18)
+#endif
+
+struct xen_memory_reservation {
+
+ /*
+ * XENMEM_increase_reservation:
+ * OUT: MFN (*not* GMFN) bases of extents that were allocated
+ * XENMEM_decrease_reservation:
+ * IN: GMFN bases of extents to free
+ * XENMEM_populate_physmap:
+ * IN: GPFN bases of extents to populate with memory
+ * OUT: GMFN bases of extents that were allocated
+ * (NB. This command also updates the mach_to_phys translation table)
+ * XENMEM_claim_pages:
+ * IN: must be zero
+ */
+ XEN_GUEST_HANDLE(xen_pfn_t) extent_start;
+
+ /* Number of extents, and size/alignment of each (2^extent_order pages). */
+ xen_ulong_t nr_extents;
+ unsigned int extent_order;
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00030209
+ /* XENMEMF flags. */
+ unsigned int mem_flags;
+#else
+ unsigned int address_bits;
+#endif
+
+ /*
+ * Domain whose reservation is being changed.
+ * Unprivileged domains can specify only DOMID_SELF.
+ */
+ domid_t domid;
+};
+typedef struct xen_memory_reservation xen_memory_reservation_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_reservation_t);
+
+/*
+ * An atomic exchange of memory pages. If return code is zero then
+ * @out.extent_list provides GMFNs of the newly-allocated memory.
+ * Returns zero on complete success, otherwise a negative error code.
+ * On complete success then always @nr_exchanged == @in.nr_extents.
+ * On partial success @nr_exchanged indicates how much work was done.
+ *
+ * Note that only PV guests can use this operation.
+ */
+#define XENMEM_exchange 11
+struct xen_memory_exchange {
+ /*
+ * [IN] Details of memory extents to be exchanged (GMFN bases).
+ * Note that @in.address_bits is ignored and unused.
+ */
+ struct xen_memory_reservation in;
+
+ /*
+ * [IN/OUT] Details of new memory extents.
+ * We require that:
+ * 1. @in.domid == @out.domid
+ * 2. @in.nr_extents << @in.extent_order ==
+ * @out.nr_extents << @out.extent_order
+ * 3. @in.extent_start and @out.extent_start lists must not overlap
+ * 4. @out.extent_start lists GPFN bases to be populated
+ * 5. @out.extent_start is overwritten with allocated GMFN bases
+ */
+ struct xen_memory_reservation out;
+
+ /*
+ * [OUT] Number of input extents that were successfully exchanged:
+ * 1. The first @nr_exchanged input extents were successfully
+ * deallocated.
+ * 2. The corresponding first entries in the output extent list correctly
+ * indicate the GMFNs that were successfully exchanged.
+ * 3. All other input and output extents are untouched.
+ * 4. If not all input exents are exchanged then the return code of this
+ * command will be non-zero.
+ * 5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
+ */
+ xen_ulong_t nr_exchanged;
+};
+typedef struct xen_memory_exchange xen_memory_exchange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_exchange_t);
+
+/*
+ * Returns the maximum machine frame number of mapped RAM in this system.
+ * This command always succeeds (it never returns an error code).
+ * arg == NULL.
+ */
+#define XENMEM_maximum_ram_page 2
+
+/*
+ * Returns the current or maximum memory reservation, in pages, of the
+ * specified domain (may be DOMID_SELF). Returns -ve errcode on failure.
+ * arg == addr of domid_t.
+ */
+#define XENMEM_current_reservation 3
+#define XENMEM_maximum_reservation 4
+
+/*
+ * Returns the maximum GPFN in use by the guest, or -ve errcode on failure.
+ */
+#define XENMEM_maximum_gpfn 14
+
+/*
+ * Returns a list of MFN bases of 2MB extents comprising the machine_to_phys
+ * mapping table. Architectures which do not have a m2p table do not implement
+ * this command.
+ * arg == addr of xen_machphys_mfn_list_t.
+ */
+#define XENMEM_machphys_mfn_list 5
+struct xen_machphys_mfn_list {
+ /*
+ * Size of the 'extent_start' array. Fewer entries will be filled if the
+ * machphys table is smaller than max_extents * 2MB.
+ */
+ unsigned int max_extents;
+
+ /*
+ * Pointer to buffer to fill with list of extent starts. If there are
+ * any large discontiguities in the machine address space, 2MB gaps in
+ * the machphys table will be represented by an MFN base of zero.
+ */
+ XEN_GUEST_HANDLE(xen_pfn_t) extent_start;
+
+ /*
+ * Number of extents written to the above array. This will be smaller
+ * than 'max_extents' if the machphys table is smaller than max_e * 2MB.
+ */
+ unsigned int nr_extents;
+};
+typedef struct xen_machphys_mfn_list xen_machphys_mfn_list_t;
+DEFINE_XEN_GUEST_HANDLE(xen_machphys_mfn_list_t);
+
+/*
+ * For a compat caller, this is identical to XENMEM_machphys_mfn_list.
+ *
+ * For a non compat caller, this functions similarly to
+ * XENMEM_machphys_mfn_list, but returns the mfns making up the compatibility
+ * m2p table.
+ */
+#define XENMEM_machphys_compat_mfn_list 25
+
+/*
+ * Returns the location in virtual address space of the machine_to_phys
+ * mapping table. Architectures which do not have a m2p table, or which do not
+ * map it by default into guest address space, do not implement this command.
+ * arg == addr of xen_machphys_mapping_t.
+ */
+#define XENMEM_machphys_mapping 12
+struct xen_machphys_mapping {
+ xen_ulong_t v_start, v_end; /* Start and end virtual addresses. */
+ xen_ulong_t max_mfn; /* Maximum MFN that can be looked up. */
+};
+typedef struct xen_machphys_mapping xen_machphys_mapping_t;
+DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
+
+/* Source mapping space. */
+/* ` enum phys_map_space { */
+#define XENMAPSPACE_shared_info 0 /* shared info page */
+#define XENMAPSPACE_grant_table 1 /* grant table page */
+#define XENMAPSPACE_gmfn 2 /* GMFN */
+#define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap only. */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+ * XENMEM_add_to_physmap_batch only. */
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region
+ ARM only; the region is mapped in
+ Stage-2 using the Normal Memory
+ Inner/Outer Write-Back Cacheable
+ memory attribute. */
+/* ` } */
+
+/*
+ * Sets the GPFN at which a particular page appears in the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_add_to_physmap_t.
+ */
+#define XENMEM_add_to_physmap 7
+struct xen_add_to_physmap {
+ /* Which domain to change the mapping for. */
+ domid_t domid;
+
+ /* Number of pages to go through for gmfn_range */
+ uint16_t size;
+
+ unsigned int space; /* => enum phys_map_space */
+
+#define XENMAPIDX_grant_table_status 0x80000000
+
+ /* Index into space being mapped. */
+ xen_ulong_t idx;
+
+ /* GPFN in domid where the source mapping page should appear. */
+ xen_pfn_t gpfn;
+};
+typedef struct xen_add_to_physmap xen_add_to_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
+
+/* A batched version of add_to_physmap. */
+#define XENMEM_add_to_physmap_batch 23
+struct xen_add_to_physmap_batch {
+ /* IN */
+ /* Which domain to change the mapping for. */
+ domid_t domid;
+ uint16_t space; /* => enum phys_map_space */
+
+ /* Number of pages to go through */
+ uint16_t size;
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040700
+ domid_t foreign_domid; /* IFF gmfn_foreign. Should be 0 for other spaces. */
+#else
+ union xen_add_to_physmap_batch_extra {
+ domid_t foreign_domid; /* gmfn_foreign */
+ uint16_t res0; /* All the other spaces. Should be 0 */
+ } u;
+#endif
+
+ /* Indexes into space being mapped. */
+ XEN_GUEST_HANDLE(xen_ulong_t) idxs;
+
+ /* GPFN in domid where the source mapping page should appear. */
+ XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
+
+ /* OUT */
+
+ /* Per index error code. */
+ XEN_GUEST_HANDLE(int) errs;
+};
+typedef struct xen_add_to_physmap_batch xen_add_to_physmap_batch_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_batch_t);
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040400
+#define XENMEM_add_to_physmap_range XENMEM_add_to_physmap_batch
+#define xen_add_to_physmap_range xen_add_to_physmap_batch
+typedef struct xen_add_to_physmap_batch xen_add_to_physmap_range_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
+#endif
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap 15
+struct xen_remove_from_physmap {
+ /* Which domain to change the mapping for. */
+ domid_t domid;
+
+ /* GPFN of the current mapping of the page. */
+ xen_pfn_t gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
+/*** REMOVED ***/
+/*#define XENMEM_translate_gpfn_list 8*/
+
+/*
+ * Returns the pseudo-physical memory map as it was when the domain
+ * was started (specified by XENMEM_set_memory_map).
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_memory_map 9
+struct xen_memory_map {
+ /*
+ * On call the number of entries which can be stored in buffer. On
+ * return the number of entries which have been stored in
+ * buffer.
+ */
+ unsigned int nr_entries;
+
+ /*
+ * Entries in the buffer are in the same format as returned by the
+ * BIOS INT 0x15 EAX=0xE820 call.
+ */
+ XEN_GUEST_HANDLE(void) buffer;
+};
+typedef struct xen_memory_map xen_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
+
+/*
+ * Returns the real physical memory map. Passes the same structure as
+ * XENMEM_memory_map.
+ * Specifying buffer as NULL will return the number of entries required
+ * to store the complete memory map.
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_machine_memory_map 10
+
+/*
+ * Set the pseudo-physical memory map of a domain, as returned by
+ * XENMEM_memory_map.
+ * arg == addr of xen_foreign_memory_map_t.
+ */
+#define XENMEM_set_memory_map 13
+struct xen_foreign_memory_map {
+ domid_t domid;
+ struct xen_memory_map map;
+};
+typedef struct xen_foreign_memory_map xen_foreign_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_foreign_memory_map_t);
+
+#define XENMEM_set_pod_target 16
+#define XENMEM_get_pod_target 17
+struct xen_pod_target {
+ /* IN */
+ uint64_t target_pages;
+ /* OUT */
+ uint64_t tot_pages;
+ uint64_t pod_cache_pages;
+ uint64_t pod_entries;
+ /* IN */
+ domid_t domid;
+};
+typedef struct xen_pod_target xen_pod_target_t;
+
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
+/*
+ * Get the number of MFNs saved through memory sharing.
+ * The call never fails.
+ */
+#define XENMEM_get_sharing_freed_pages 18
+#define XENMEM_get_sharing_shared_pages 19
+
+#define XENMEM_paging_op 20
+#define XENMEM_paging_op_nominate 0
+#define XENMEM_paging_op_evict 1
+#define XENMEM_paging_op_prep 2
+
+struct xen_mem_paging_op {
+ uint8_t op; /* XENMEM_paging_op_* */
+ domid_t domain;
+
+ /* PAGING_PREP IN: buffer to immediately fill page in */
+ uint64_aligned_t buffer;
+ /* Other OPs */
+ uint64_aligned_t gfn; /* IN: gfn of page being operated on */
+};
+typedef struct xen_mem_paging_op xen_mem_paging_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t);
+
+#define XENMEM_access_op 21
+#define XENMEM_access_op_set_access 0
+#define XENMEM_access_op_get_access 1
+/*
+ * XENMEM_access_op_enable_emulate and XENMEM_access_op_disable_emulate are
+ * currently unused, but since they have been in use please do not reuse them.
+ *
+ * #define XENMEM_access_op_enable_emulate 2
+ * #define XENMEM_access_op_disable_emulate 3
+ */
+#define XENMEM_access_op_set_access_multi 4
+
+typedef enum {
+ XENMEM_access_n,
+ XENMEM_access_r,
+ XENMEM_access_w,
+ XENMEM_access_rw,
+ XENMEM_access_x,
+ XENMEM_access_rx,
+ XENMEM_access_wx,
+ XENMEM_access_rwx,
+ /*
+ * Page starts off as r-x, but automatically
+ * change to r-w on a write
+ */
+ XENMEM_access_rx2rw,
+ /*
+ * Log access: starts off as n, automatically
+ * goes to rwx, generating an event without
+ * pausing the vcpu
+ */
+ XENMEM_access_n2rwx,
+ /* Take the domain default */
+ XENMEM_access_default
+} xenmem_access_t;
+
+struct xen_mem_access_op {
+ /* XENMEM_access_op_* */
+ uint8_t op;
+ /* xenmem_access_t */
+ uint8_t access;
+ domid_t domid;
+ /*
+ * Number of pages for set op (or size of pfn_list for
+ * XENMEM_access_op_set_access_multi)
+ * Ignored on setting default access and other ops
+ */
+ uint32_t nr;
+ /*
+ * First pfn for set op
+ * pfn for get op
+ * ~0ull is used to set and get the default access for pages
+ */
+ uint64_aligned_t pfn;
+ /*
+ * List of pfns to set access for
+ * Used only with XENMEM_access_op_set_access_multi
+ */
+ XEN_GUEST_HANDLE(const_uint64) pfn_list;
+ /*
+ * Corresponding list of access settings for pfn_list
+ * Used only with XENMEM_access_op_set_access_multi
+ */
+ XEN_GUEST_HANDLE(const_uint8) access_list;
+};
+typedef struct xen_mem_access_op xen_mem_access_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_access_op_t);
+
+#define XENMEM_sharing_op 22
+#define XENMEM_sharing_op_nominate_gfn 0
+#define XENMEM_sharing_op_nominate_gref 1
+#define XENMEM_sharing_op_share 2
+#define XENMEM_sharing_op_debug_gfn 3
+#define XENMEM_sharing_op_debug_mfn 4
+#define XENMEM_sharing_op_debug_gref 5
+#define XENMEM_sharing_op_add_physmap 6
+#define XENMEM_sharing_op_audit 7
+#define XENMEM_sharing_op_range_share 8
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG (xen_mk_ullong(1) << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val) \
+ (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field) \
+ ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field) \
+ ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+ uint8_t op; /* XENMEM_sharing_op_* */
+ domid_t domain;
+
+ union {
+ struct mem_sharing_op_nominate { /* OP_NOMINATE_xxx */
+ union {
+ uint64_aligned_t gfn; /* IN: gfn to nominate */
+ uint32_t grant_ref; /* IN: grant ref to nominate */
+ } u;
+ uint64_aligned_t handle; /* OUT: the handle */
+ } nominate;
+ struct mem_sharing_op_share { /* OP_SHARE/ADD_PHYSMAP */
+ uint64_aligned_t source_gfn; /* IN: the gfn of the source page */
+ uint64_aligned_t source_handle; /* IN: handle to the source page */
+ uint64_aligned_t client_gfn; /* IN: the client gfn */
+ uint64_aligned_t client_handle; /* IN: handle to the client page */
+ domid_t client_domain; /* IN: the client domain id */
+ } share;
+ struct mem_sharing_op_range { /* OP_RANGE_SHARE */
+ uint64_aligned_t first_gfn; /* IN: the first gfn */
+ uint64_aligned_t last_gfn; /* IN: the last gfn */
+ uint64_aligned_t opaque; /* Must be set to 0 */
+ domid_t client_domain; /* IN: the client domain id */
+ uint16_t _pad[3]; /* Must be set to 0 */
+ } range;
+ struct mem_sharing_op_debug { /* OP_DEBUG_xxx */
+ union {
+ uint64_aligned_t gfn; /* IN: gfn to debug */
+ uint64_aligned_t mfn; /* IN: mfn to debug */
+ uint32_t gref; /* IN: gref to debug */
+ } u;
+ } debug;
+ } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+/*
+ * Attempt to stake a claim for a domain on a quantity of pages
+ * of system RAM, but _not_ assign specific pageframes. Only
+ * arithmetic is performed so the hypercall is very fast and need
+ * not be preemptible, thus sidestepping time-of-check-time-of-use
+ * races for memory allocation. Returns 0 if the hypervisor page
+ * allocator has atomically and successfully claimed the requested
+ * number of pages, else non-zero.
+ *
+ * Any domain may have only one active claim. When sufficient memory
+ * has been allocated to resolve the claim, the claim silently expires.
+ * Claiming zero pages effectively resets any outstanding claim and
+ * is always successful.
+ *
+ * Note that a valid claim may be staked even after memory has been
+ * allocated for a domain. In this case, the claim is not incremental,
+ * i.e. if the domain's tot_pages is 3, and a claim is staked for 10,
+ * only 7 additional pages are claimed.
+ *
+ * Caller must be privileged or the hypercall fails.
+ */
+#define XENMEM_claim_pages 24
+
+/*
+ * XENMEM_claim_pages flags - the are no flags at this time.
+ * The zero value is appropriate.
+ */
+
+/*
+ * With some legacy devices, certain guest-physical addresses cannot safely
+ * be used for other purposes, e.g. to map guest RAM. This hypercall
+ * enumerates those regions so the toolstack can avoid using them.
+ */
+#define XENMEM_reserved_device_memory_map 27
+struct xen_reserved_device_memory {
+ xen_pfn_t start_pfn;
+ xen_ulong_t nr_pages;
+};
+typedef struct xen_reserved_device_memory xen_reserved_device_memory_t;
+DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_t);
+
+struct xen_reserved_device_memory_map {
+#define XENMEM_RDM_ALL 1 /* Request all regions (ignore dev union). */
+ /* IN */
+ uint32_t flags;
+ /*
+ * IN/OUT
+ *
+ * Gets set to the required number of entries when too low,
+ * signaled by error code -ERANGE.
+ */
+ unsigned int nr_entries;
+ /* OUT */
+ XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
+ /* IN */
+ union {
+ struct physdev_pci_device pci;
+ } dev;
+};
+typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
+/*
+ * XENMEM_get_vnumainfo used by guest to get
+ * vNUMA topology from hypervisor.
+ */
+#define XENMEM_get_vnumainfo 26
+
+/* vNUMA node memory ranges */
+struct xen_vmemrange {
+ uint64_t start, end;
+ unsigned int flags;
+ unsigned int nid;
+};
+typedef struct xen_vmemrange xen_vmemrange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
+
+/*
+ * vNUMA topology specifies vNUMA node number, distance table,
+ * memory ranges and vcpu mapping provided for guests.
+ * XENMEM_get_vnumainfo hypercall expects to see from guest
+ * nr_vnodes, nr_vmemranges and nr_vcpus to indicate available memory.
+ * After filling guests structures, nr_vnodes, nr_vmemranges and nr_vcpus
+ * copied back to guest. Domain returns expected values of nr_vnodes,
+ * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
+ */
+struct xen_vnuma_topology_info {
+ /* IN */
+ domid_t domid;
+ uint16_t pad;
+ /* IN/OUT */
+ unsigned int nr_vnodes;
+ unsigned int nr_vcpus;
+ unsigned int nr_vmemranges;
+ /* OUT */
+ union {
+ XEN_GUEST_HANDLE(uint) h;
+ uint64_t pad;
+ } vdistance;
+ union {
+ XEN_GUEST_HANDLE(uint) h;
+ uint64_t pad;
+ } vcpu_to_vnode;
+ union {
+ XEN_GUEST_HANDLE(xen_vmemrange_t) h;
+ uint64_t pad;
+ } vmemrange;
+};
+typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
+
+/* Next available subop number is 28 */
+
+#endif /* __XEN_PUBLIC_MEMORY_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/physdev.h b/include/xen/physdev.h
new file mode 100644
index 000000000..0e5463562
--- /dev/null
+++ b/include/xen/physdev.h
@@ -0,0 +1,387 @@
+/*
+ * 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) 2006, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_PHYSDEV_H__
+#define __XEN_PUBLIC_PHYSDEV_H__
+
+#include "xen.h"
+
+/*
+ * Prototype for this hypercall is:
+ * int physdev_op(int cmd, void *args)
+ * @cmd == PHYSDEVOP_??? (physdev operation).
+ * @args == Operation-specific extra arguments (NULL if none).
+ */
+
+/*
+ * Notify end-of-interrupt (EOI) for the specified IRQ.
+ * @arg == pointer to physdev_eoi structure.
+ */
+#define PHYSDEVOP_eoi 12
+struct physdev_eoi {
+ /* IN */
+ uint32_t irq;
+};
+typedef struct physdev_eoi physdev_eoi_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
+
+/*
+ * Register a shared page for the hypervisor to indicate whether the guest
+ * must issue PHYSDEVOP_eoi. The semantics of PHYSDEVOP_eoi change slightly
+ * once the guest used this function in that the associated event channel
+ * will automatically get unmasked. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v1 17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2 28
+struct physdev_pirq_eoi_gmfn {
+ /* IN */
+ xen_pfn_t gmfn;
+};
+typedef struct physdev_pirq_eoi_gmfn physdev_pirq_eoi_gmfn_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pirq_eoi_gmfn_t);
+
+/*
+ * Query the status of an IRQ line.
+ * @arg == pointer to physdev_irq_status_query structure.
+ */
+#define PHYSDEVOP_irq_status_query 5
+struct physdev_irq_status_query {
+ /* IN */
+ uint32_t irq;
+ /* OUT */
+ uint32_t flags; /* XENIRQSTAT_* */
+};
+typedef struct physdev_irq_status_query physdev_irq_status_query_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_irq_status_query_t);
+
+/* Need to call PHYSDEVOP_eoi when the IRQ has been serviced? */
+#define _XENIRQSTAT_needs_eoi (0)
+#define XENIRQSTAT_needs_eoi (1U<<_XENIRQSTAT_needs_eoi)
+
+/* IRQ shared by multiple guests? */
+#define _XENIRQSTAT_shared (1)
+#define XENIRQSTAT_shared (1U<<_XENIRQSTAT_shared)
+
+/*
+ * Set the current VCPU's I/O privilege level.
+ * @arg == pointer to physdev_set_iopl structure.
+ */
+#define PHYSDEVOP_set_iopl 6
+struct physdev_set_iopl {
+ /* IN */
+ uint32_t iopl;
+};
+typedef struct physdev_set_iopl physdev_set_iopl_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_set_iopl_t);
+
+/*
+ * Set the current VCPU's I/O-port permissions bitmap.
+ * @arg == pointer to physdev_set_iobitmap structure.
+ */
+#define PHYSDEVOP_set_iobitmap 7
+struct physdev_set_iobitmap {
+ /* IN */
+#if __XEN_INTERFACE_VERSION__ >= 0x00030205
+ XEN_GUEST_HANDLE(uint8) bitmap;
+#else
+ uint8_t *bitmap;
+#endif
+ uint32_t nr_ports;
+};
+typedef struct physdev_set_iobitmap physdev_set_iobitmap_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_set_iobitmap_t);
+
+/*
+ * Read or write an IO-APIC register.
+ * @arg == pointer to physdev_apic structure.
+ */
+#define PHYSDEVOP_apic_read 8
+#define PHYSDEVOP_apic_write 9
+struct physdev_apic {
+ /* IN */
+ unsigned long apic_physbase;
+ uint32_t reg;
+ /* IN or OUT */
+ uint32_t value;
+};
+typedef struct physdev_apic physdev_apic_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_apic_t);
+
+/*
+ * Allocate or free a physical upcall vector for the specified IRQ line.
+ * @arg == pointer to physdev_irq structure.
+ */
+#define PHYSDEVOP_alloc_irq_vector 10
+#define PHYSDEVOP_free_irq_vector 11
+struct physdev_irq {
+ /* IN */
+ uint32_t irq;
+ /* IN or OUT */
+ uint32_t vector;
+};
+typedef struct physdev_irq physdev_irq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_irq_t);
+
+#define MAP_PIRQ_TYPE_MSI 0x0
+#define MAP_PIRQ_TYPE_GSI 0x1
+#define MAP_PIRQ_TYPE_UNKNOWN 0x2
+#define MAP_PIRQ_TYPE_MSI_SEG 0x3
+#define MAP_PIRQ_TYPE_MULTI_MSI 0x4
+
+#define PHYSDEVOP_map_pirq 13
+struct physdev_map_pirq {
+ domid_t domid;
+ /* IN */
+ int type;
+ /* IN (ignored for ..._MULTI_MSI) */
+ int index;
+ /* IN or OUT */
+ int pirq;
+ /* IN - high 16 bits hold segment for ..._MSI_SEG and ..._MULTI_MSI */
+ int bus;
+ /* IN */
+ int devfn;
+ /* IN (also OUT for ..._MULTI_MSI) */
+ int entry_nr;
+ /* IN */
+ uint64_t table_base;
+};
+typedef struct physdev_map_pirq physdev_map_pirq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_map_pirq_t);
+
+#define PHYSDEVOP_unmap_pirq 14
+struct physdev_unmap_pirq {
+ domid_t domid;
+ /* IN */
+ int pirq;
+};
+
+typedef struct physdev_unmap_pirq physdev_unmap_pirq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_unmap_pirq_t);
+
+#define PHYSDEVOP_manage_pci_add 15
+#define PHYSDEVOP_manage_pci_remove 16
+struct physdev_manage_pci {
+ /* IN */
+ uint8_t bus;
+ uint8_t devfn;
+};
+
+typedef struct physdev_manage_pci physdev_manage_pci_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_manage_pci_t);
+
+#define PHYSDEVOP_restore_msi 19
+struct physdev_restore_msi {
+ /* IN */
+ uint8_t bus;
+ uint8_t devfn;
+};
+typedef struct physdev_restore_msi physdev_restore_msi_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_restore_msi_t);
+
+#define PHYSDEVOP_manage_pci_add_ext 20
+struct physdev_manage_pci_ext {
+ /* IN */
+ uint8_t bus;
+ uint8_t devfn;
+ unsigned is_extfn;
+ unsigned is_virtfn;
+ struct {
+ uint8_t bus;
+ uint8_t devfn;
+ } physfn;
+};
+
+typedef struct physdev_manage_pci_ext physdev_manage_pci_ext_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_manage_pci_ext_t);
+
+/*
+ * Argument to physdev_op_compat() hypercall. Superceded by new physdev_op()
+ * hypercall since 0x00030202.
+ */
+struct physdev_op {
+ uint32_t cmd;
+ union {
+ struct physdev_irq_status_query irq_status_query;
+ struct physdev_set_iopl set_iopl;
+ struct physdev_set_iobitmap set_iobitmap;
+ struct physdev_apic apic_op;
+ struct physdev_irq irq_op;
+ } u;
+};
+typedef struct physdev_op physdev_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_op_t);
+
+#define PHYSDEVOP_setup_gsi 21
+struct physdev_setup_gsi {
+ int gsi;
+ /* IN */
+ uint8_t triggering;
+ /* IN */
+ uint8_t polarity;
+ /* IN */
+};
+
+typedef struct physdev_setup_gsi physdev_setup_gsi_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_setup_gsi_t);
+
+/* leave PHYSDEVOP 22 free */
+
+/* type is MAP_PIRQ_TYPE_GSI or MAP_PIRQ_TYPE_MSI
+ * the hypercall returns a free pirq */
+#define PHYSDEVOP_get_free_pirq 23
+struct physdev_get_free_pirq {
+ /* IN */
+ int type;
+ /* OUT */
+ uint32_t pirq;
+};
+
+typedef struct physdev_get_free_pirq physdev_get_free_pirq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_get_free_pirq_t);
+
+#define XEN_PCI_MMCFG_RESERVED 0x1
+
+#define PHYSDEVOP_pci_mmcfg_reserved 24
+struct physdev_pci_mmcfg_reserved {
+ uint64_t address;
+ uint16_t segment;
+ uint8_t start_bus;
+ uint8_t end_bus;
+ uint32_t flags;
+};
+typedef struct physdev_pci_mmcfg_reserved physdev_pci_mmcfg_reserved_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pci_mmcfg_reserved_t);
+
+#define XEN_PCI_DEV_EXTFN 0x1
+#define XEN_PCI_DEV_VIRTFN 0x2
+#define XEN_PCI_DEV_PXM 0x4
+
+#define PHYSDEVOP_pci_device_add 25
+struct physdev_pci_device_add {
+ /* IN */
+ uint16_t seg;
+ uint8_t bus;
+ uint8_t devfn;
+ uint32_t flags;
+ struct {
+ uint8_t bus;
+ uint8_t devfn;
+ } physfn;
+ /*
+ * Optional parameters array.
+ * First element ([0]) is PXM domain associated with the device (if
+ * XEN_PCI_DEV_PXM is set)
+ */
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
+ uint32_t optarr[];
+#elif defined(__GNUC__)
+ uint32_t optarr[0];
+#endif
+};
+typedef struct physdev_pci_device_add physdev_pci_device_add_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_add_t);
+
+#define PHYSDEVOP_pci_device_remove 26
+#define PHYSDEVOP_restore_msi_ext 27
+/*
+ * Dom0 should use these two to announce MMIO resources assigned to
+ * MSI-X capable devices won't (prepare) or may (release) change.
+ */
+#define PHYSDEVOP_prepare_msix 30
+#define PHYSDEVOP_release_msix 31
+struct physdev_pci_device {
+ /* IN */
+ uint16_t seg;
+ uint8_t bus;
+ uint8_t devfn;
+};
+typedef struct physdev_pci_device physdev_pci_device_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
+
+#define PHYSDEVOP_DBGP_RESET_PREPARE 1
+#define PHYSDEVOP_DBGP_RESET_DONE 2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN 0
+#define PHYSDEVOP_DBGP_BUS_PCI 1
+
+#define PHYSDEVOP_dbgp_op 29
+struct physdev_dbgp_op {
+ /* IN */
+ uint8_t op;
+ uint8_t bus;
+ union {
+ struct physdev_pci_device pci;
+ } u;
+};
+typedef struct physdev_dbgp_op physdev_dbgp_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
+
+/*
+ * Notify that some PIRQ-bound event channels have been unmasked.
+ * ** This command is obsolete since interface version 0x00030202 and is **
+ * ** unsupported by newer versions of Xen. **
+ */
+#define PHYSDEVOP_IRQ_UNMASK_NOTIFY 4
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040600
+/*
+ * These all-capitals physdev operation names are superceded by the new names
+ * (defined above) since interface version 0x00030202. The guard above was
+ * added post-4.5 only though and hence shouldn't check for 0x00030202.
+ */
+#define PHYSDEVOP_IRQ_STATUS_QUERY PHYSDEVOP_irq_status_query
+#define PHYSDEVOP_SET_IOPL PHYSDEVOP_set_iopl
+#define PHYSDEVOP_SET_IOBITMAP PHYSDEVOP_set_iobitmap
+#define PHYSDEVOP_APIC_READ PHYSDEVOP_apic_read
+#define PHYSDEVOP_APIC_WRITE PHYSDEVOP_apic_write
+#define PHYSDEVOP_ASSIGN_VECTOR PHYSDEVOP_alloc_irq_vector
+#define PHYSDEVOP_FREE_VECTOR PHYSDEVOP_free_irq_vector
+#define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi
+#define PHYSDEVOP_IRQ_SHARED XENIRQSTAT_shared
+#endif
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040200
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
+#else
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
+#endif
+
+#endif /* __XEN_PUBLIC_PHYSDEV_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/trace.h b/include/xen/trace.h
new file mode 100644
index 000000000..3746bff26
--- /dev/null
+++ b/include/xen/trace.h
@@ -0,0 +1,339 @@
+/******************************************************************************
+ * include/public/trace.h
+ *
+ * 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.
+ *
+ * Mark Williamson, (C) 2004 Intel Research Cambridge
+ * Copyright (C) 2005 Bin Ren
+ */
+
+#ifndef __XEN_PUBLIC_TRACE_H__
+#define __XEN_PUBLIC_TRACE_H__
+
+#define TRACE_EXTRA_MAX 7
+#define TRACE_EXTRA_SHIFT 28
+
+/* Trace classes */
+#define TRC_CLS_SHIFT 16
+#define TRC_GEN 0x0001f000 /* General trace */
+#define TRC_SCHED 0x0002f000 /* Xen Scheduler trace */
+#define TRC_DOM0OP 0x0004f000 /* Xen DOM0 operation trace */
+#define TRC_HVM 0x0008f000 /* Xen HVM trace */
+#define TRC_MEM 0x0010f000 /* Xen memory trace */
+#define TRC_PV 0x0020f000 /* Xen PV traces */
+#define TRC_SHADOW 0x0040f000 /* Xen shadow tracing */
+#define TRC_HW 0x0080f000 /* Xen hardware-related traces */
+#define TRC_GUEST 0x0800f000 /* Guest-generated traces */
+#define TRC_ALL 0x0ffff000
+#define TRC_HD_TO_EVENT(x) ((x)&0x0fffffff)
+#define TRC_HD_CYCLE_FLAG (1UL<<31)
+#define TRC_HD_INCLUDES_CYCLE_COUNT(x) ( !!( (x) & TRC_HD_CYCLE_FLAG ) )
+#define TRC_HD_EXTRA(x) (((x)>>TRACE_EXTRA_SHIFT)&TRACE_EXTRA_MAX)
+
+/* Trace subclasses */
+#define TRC_SUBCLS_SHIFT 12
+
+/* trace subclasses for SVM */
+#define TRC_HVM_ENTRYEXIT 0x00081000 /* VMENTRY and #VMEXIT */
+#define TRC_HVM_HANDLER 0x00082000 /* various HVM handlers */
+#define TRC_HVM_EMUL 0x00084000 /* emulated devices */
+
+#define TRC_SCHED_MIN 0x00021000 /* Just runstate changes */
+#define TRC_SCHED_CLASS 0x00022000 /* Scheduler-specific */
+#define TRC_SCHED_VERBOSE 0x00028000 /* More inclusive scheduling */
+
+/*
+ * The highest 3 bits of the last 12 bits of TRC_SCHED_CLASS above are
+ * reserved for encoding what scheduler produced the information. The
+ * actual event is encoded in the last 9 bits.
+ *
+ * This means we have 8 scheduling IDs available (which means at most 8
+ * schedulers generating events) and, in each scheduler, up to 512
+ * different events.
+ */
+#define TRC_SCHED_ID_BITS 3
+#define TRC_SCHED_ID_SHIFT (TRC_SUBCLS_SHIFT - TRC_SCHED_ID_BITS)
+#define TRC_SCHED_ID_MASK (((1UL<<TRC_SCHED_ID_BITS) - 1) << TRC_SCHED_ID_SHIFT)
+#define TRC_SCHED_EVT_MASK (~(TRC_SCHED_ID_MASK))
+
+/* Per-scheduler IDs, to identify scheduler specific events */
+#define TRC_SCHED_CSCHED 0
+#define TRC_SCHED_CSCHED2 1
+/* #define XEN_SCHEDULER_SEDF 2 (Removed) */
+#define TRC_SCHED_ARINC653 3
+#define TRC_SCHED_RTDS 4
+#define TRC_SCHED_SNULL 5
+
+/* Per-scheduler tracing */
+#define TRC_SCHED_CLASS_EVT(_c, _e) \
+ ( ( TRC_SCHED_CLASS | \
+ ((TRC_SCHED_##_c << TRC_SCHED_ID_SHIFT) & TRC_SCHED_ID_MASK) ) + \
+ (_e & TRC_SCHED_EVT_MASK) )
+
+/* Trace classes for DOM0 operations */
+#define TRC_DOM0_DOMOPS 0x00041000 /* Domains manipulations */
+
+/* Trace classes for Hardware */
+#define TRC_HW_PM 0x00801000 /* Power management traces */
+#define TRC_HW_IRQ 0x00802000 /* Traces relating to the handling of IRQs */
+
+/* Trace events per class */
+#define TRC_LOST_RECORDS (TRC_GEN + 1)
+#define TRC_TRACE_WRAP_BUFFER (TRC_GEN + 2)
+#define TRC_TRACE_CPU_CHANGE (TRC_GEN + 3)
+
+#define TRC_SCHED_RUNSTATE_CHANGE (TRC_SCHED_MIN + 1)
+#define TRC_SCHED_CONTINUE_RUNNING (TRC_SCHED_MIN + 2)
+#define TRC_SCHED_DOM_ADD (TRC_SCHED_VERBOSE + 1)
+#define TRC_SCHED_DOM_REM (TRC_SCHED_VERBOSE + 2)
+#define TRC_SCHED_SLEEP (TRC_SCHED_VERBOSE + 3)
+#define TRC_SCHED_WAKE (TRC_SCHED_VERBOSE + 4)
+#define TRC_SCHED_YIELD (TRC_SCHED_VERBOSE + 5)
+#define TRC_SCHED_BLOCK (TRC_SCHED_VERBOSE + 6)
+#define TRC_SCHED_SHUTDOWN (TRC_SCHED_VERBOSE + 7)
+#define TRC_SCHED_CTL (TRC_SCHED_VERBOSE + 8)
+#define TRC_SCHED_ADJDOM (TRC_SCHED_VERBOSE + 9)
+#define TRC_SCHED_SWITCH (TRC_SCHED_VERBOSE + 10)
+#define TRC_SCHED_S_TIMER_FN (TRC_SCHED_VERBOSE + 11)
+#define TRC_SCHED_T_TIMER_FN (TRC_SCHED_VERBOSE + 12)
+#define TRC_SCHED_DOM_TIMER_FN (TRC_SCHED_VERBOSE + 13)
+#define TRC_SCHED_SWITCH_INFPREV (TRC_SCHED_VERBOSE + 14)
+#define TRC_SCHED_SWITCH_INFNEXT (TRC_SCHED_VERBOSE + 15)
+#define TRC_SCHED_SHUTDOWN_CODE (TRC_SCHED_VERBOSE + 16)
+#define TRC_SCHED_SWITCH_INFCONT (TRC_SCHED_VERBOSE + 17)
+
+#define TRC_DOM0_DOM_ADD (TRC_DOM0_DOMOPS + 1)
+#define TRC_DOM0_DOM_REM (TRC_DOM0_DOMOPS + 2)
+
+#define TRC_MEM_PAGE_GRANT_MAP (TRC_MEM + 1)
+#define TRC_MEM_PAGE_GRANT_UNMAP (TRC_MEM + 2)
+#define TRC_MEM_PAGE_GRANT_TRANSFER (TRC_MEM + 3)
+#define TRC_MEM_SET_P2M_ENTRY (TRC_MEM + 4)
+#define TRC_MEM_DECREASE_RESERVATION (TRC_MEM + 5)
+#define TRC_MEM_POD_POPULATE (TRC_MEM + 16)
+#define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17)
+#define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
+
+#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */
+#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */
+
+#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1)
+#define TRC_PV_TRAP (TRC_PV_ENTRY + 3)
+#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4)
+#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5)
+#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6)
+#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7)
+#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8)
+#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9)
+#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10)
+#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11)
+#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12)
+#define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13)
+#define TRC_PV_HYPERCALL_SUBCALL (TRC_PV_SUBCALL + 14)
+
+/*
+ * TRC_PV_HYPERCALL_V2 format
+ *
+ * Only some of the hypercall argument are recorded. Bit fields A0 to
+ * A5 in the first extra word are set if the argument is present and
+ * the arguments themselves are packed sequentially in the following
+ * words.
+ *
+ * The TRC_64_FLAG bit is not set for these events (even if there are
+ * 64-bit arguments in the record).
+ *
+ * Word
+ * 0 bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0
+ * A5 |A4 |A3 |A2 |A1 |A0 |Hypercall op
+ * 1 First 32 bit (or low word of first 64 bit) arg in record
+ * 2 Second 32 bit (or high word of first 64 bit) arg in record
+ * ...
+ *
+ * A0-A5 bitfield values:
+ *
+ * 00b Argument not present
+ * 01b 32-bit argument present
+ * 10b 64-bit argument present
+ * 11b Reserved
+ */
+#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1 << (20 + 2*(i)))
+#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2 << (20 + 2*(i)))
+#define TRC_PV_HYPERCALL_V2_ARG_MASK (0xfff00000)
+
+#define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1)
+#define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2)
+#define TRC_SHADOW_FAST_MMIO (TRC_SHADOW + 3)
+#define TRC_SHADOW_FALSE_FAST_PATH (TRC_SHADOW + 4)
+#define TRC_SHADOW_MMIO (TRC_SHADOW + 5)
+#define TRC_SHADOW_FIXUP (TRC_SHADOW + 6)
+#define TRC_SHADOW_DOMF_DYING (TRC_SHADOW + 7)
+#define TRC_SHADOW_EMULATE (TRC_SHADOW + 8)
+#define TRC_SHADOW_EMULATE_UNSHADOW_USER (TRC_SHADOW + 9)
+#define TRC_SHADOW_EMULATE_UNSHADOW_EVTINJ (TRC_SHADOW + 10)
+#define TRC_SHADOW_EMULATE_UNSHADOW_UNHANDLED (TRC_SHADOW + 11)
+#define TRC_SHADOW_WRMAP_BF (TRC_SHADOW + 12)
+#define TRC_SHADOW_PREALLOC_UNPIN (TRC_SHADOW + 13)
+#define TRC_SHADOW_RESYNC_FULL (TRC_SHADOW + 14)
+#define TRC_SHADOW_RESYNC_ONLY (TRC_SHADOW + 15)
+
+/* trace events per subclass */
+#define TRC_HVM_NESTEDFLAG (0x400)
+#define TRC_HVM_VMENTRY (TRC_HVM_ENTRYEXIT + 0x01)
+#define TRC_HVM_VMEXIT (TRC_HVM_ENTRYEXIT + 0x02)
+#define TRC_HVM_VMEXIT64 (TRC_HVM_ENTRYEXIT + TRC_64_FLAG + 0x02)
+#define TRC_HVM_PF_XEN (TRC_HVM_HANDLER + 0x01)
+#define TRC_HVM_PF_XEN64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x01)
+#define TRC_HVM_PF_INJECT (TRC_HVM_HANDLER + 0x02)
+#define TRC_HVM_PF_INJECT64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x02)
+#define TRC_HVM_INJ_EXC (TRC_HVM_HANDLER + 0x03)
+#define TRC_HVM_INJ_VIRQ (TRC_HVM_HANDLER + 0x04)
+#define TRC_HVM_REINJ_VIRQ (TRC_HVM_HANDLER + 0x05)
+#define TRC_HVM_IO_READ (TRC_HVM_HANDLER + 0x06)
+#define TRC_HVM_IO_WRITE (TRC_HVM_HANDLER + 0x07)
+#define TRC_HVM_CR_READ (TRC_HVM_HANDLER + 0x08)
+#define TRC_HVM_CR_READ64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x08)
+#define TRC_HVM_CR_WRITE (TRC_HVM_HANDLER + 0x09)
+#define TRC_HVM_CR_WRITE64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x09)
+#define TRC_HVM_DR_READ (TRC_HVM_HANDLER + 0x0A)
+#define TRC_HVM_DR_WRITE (TRC_HVM_HANDLER + 0x0B)
+#define TRC_HVM_MSR_READ (TRC_HVM_HANDLER + 0x0C)
+#define TRC_HVM_MSR_WRITE (TRC_HVM_HANDLER + 0x0D)
+#define TRC_HVM_CPUID (TRC_HVM_HANDLER + 0x0E)
+#define TRC_HVM_INTR (TRC_HVM_HANDLER + 0x0F)
+#define TRC_HVM_NMI (TRC_HVM_HANDLER + 0x10)
+#define TRC_HVM_SMI (TRC_HVM_HANDLER + 0x11)
+#define TRC_HVM_VMMCALL (TRC_HVM_HANDLER + 0x12)
+#define TRC_HVM_HLT (TRC_HVM_HANDLER + 0x13)
+#define TRC_HVM_INVLPG (TRC_HVM_HANDLER + 0x14)
+#define TRC_HVM_INVLPG64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x14)
+#define TRC_HVM_MCE (TRC_HVM_HANDLER + 0x15)
+#define TRC_HVM_IOPORT_READ (TRC_HVM_HANDLER + 0x16)
+#define TRC_HVM_IOMEM_READ (TRC_HVM_HANDLER + 0x17)
+#define TRC_HVM_CLTS (TRC_HVM_HANDLER + 0x18)
+#define TRC_HVM_LMSW (TRC_HVM_HANDLER + 0x19)
+#define TRC_HVM_LMSW64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x19)
+#define TRC_HVM_RDTSC (TRC_HVM_HANDLER + 0x1a)
+#define TRC_HVM_INTR_WINDOW (TRC_HVM_HANDLER + 0x20)
+#define TRC_HVM_NPF (TRC_HVM_HANDLER + 0x21)
+#define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
+#define TRC_HVM_TRAP (TRC_HVM_HANDLER + 0x23)
+#define TRC_HVM_TRAP_DEBUG (TRC_HVM_HANDLER + 0x24)
+#define TRC_HVM_VLAPIC (TRC_HVM_HANDLER + 0x25)
+
+#define TRC_HVM_IOPORT_WRITE (TRC_HVM_HANDLER + 0x216)
+#define TRC_HVM_IOMEM_WRITE (TRC_HVM_HANDLER + 0x217)
+
+/* Trace events for emulated devices */
+#define TRC_HVM_EMUL_HPET_START_TIMER (TRC_HVM_EMUL + 0x1)
+#define TRC_HVM_EMUL_PIT_START_TIMER (TRC_HVM_EMUL + 0x2)
+#define TRC_HVM_EMUL_RTC_START_TIMER (TRC_HVM_EMUL + 0x3)
+#define TRC_HVM_EMUL_LAPIC_START_TIMER (TRC_HVM_EMUL + 0x4)
+#define TRC_HVM_EMUL_HPET_STOP_TIMER (TRC_HVM_EMUL + 0x5)
+#define TRC_HVM_EMUL_PIT_STOP_TIMER (TRC_HVM_EMUL + 0x6)
+#define TRC_HVM_EMUL_RTC_STOP_TIMER (TRC_HVM_EMUL + 0x7)
+#define TRC_HVM_EMUL_LAPIC_STOP_TIMER (TRC_HVM_EMUL + 0x8)
+#define TRC_HVM_EMUL_PIT_TIMER_CB (TRC_HVM_EMUL + 0x9)
+#define TRC_HVM_EMUL_LAPIC_TIMER_CB (TRC_HVM_EMUL + 0xA)
+#define TRC_HVM_EMUL_PIC_INT_OUTPUT (TRC_HVM_EMUL + 0xB)
+#define TRC_HVM_EMUL_PIC_KICK (TRC_HVM_EMUL + 0xC)
+#define TRC_HVM_EMUL_PIC_INTACK (TRC_HVM_EMUL + 0xD)
+#define TRC_HVM_EMUL_PIC_POSEDGE (TRC_HVM_EMUL + 0xE)
+#define TRC_HVM_EMUL_PIC_NEGEDGE (TRC_HVM_EMUL + 0xF)
+#define TRC_HVM_EMUL_PIC_PEND_IRQ_CALL (TRC_HVM_EMUL + 0x10)
+#define TRC_HVM_EMUL_LAPIC_PIC_INTR (TRC_HVM_EMUL + 0x11)
+
+/* trace events for per class */
+#define TRC_PM_FREQ_CHANGE (TRC_HW_PM + 0x01)
+#define TRC_PM_IDLE_ENTRY (TRC_HW_PM + 0x02)
+#define TRC_PM_IDLE_EXIT (TRC_HW_PM + 0x03)
+
+/* Trace events for IRQs */
+#define TRC_HW_IRQ_MOVE_CLEANUP_DELAY (TRC_HW_IRQ + 0x1)
+#define TRC_HW_IRQ_MOVE_CLEANUP (TRC_HW_IRQ + 0x2)
+#define TRC_HW_IRQ_BIND_VECTOR (TRC_HW_IRQ + 0x3)
+#define TRC_HW_IRQ_CLEAR_VECTOR (TRC_HW_IRQ + 0x4)
+#define TRC_HW_IRQ_MOVE_FINISH (TRC_HW_IRQ + 0x5)
+#define TRC_HW_IRQ_ASSIGN_VECTOR (TRC_HW_IRQ + 0x6)
+#define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7)
+#define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8)
+
+/*
+ * Event Flags
+ *
+ * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple
+ * record formats. These event flags distinguish between the
+ * different formats.
+ */
+#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */
+
+/* This structure represents a single trace buffer record. */
+struct t_rec {
+ uint32_t event:28;
+ uint32_t extra_u32:3; /* # entries in trailing extra_u32[] array */
+ uint32_t cycles_included:1; /* u.cycles or u.no_cycles? */
+ union {
+ struct {
+ uint32_t cycles_lo, cycles_hi; /* cycle counter timestamp */
+ uint32_t extra_u32[7]; /* event data items */
+ } cycles;
+ struct {
+ uint32_t extra_u32[7]; /* event data items */
+ } nocycles;
+ } u;
+};
+
+/*
+ * This structure contains the metadata for a single trace buffer. The head
+ * field, indexes into an array of struct t_rec's.
+ */
+struct t_buf {
+ /* Assume the data buffer size is X. X is generally not a power of 2.
+ * CONS and PROD are incremented modulo (2*X):
+ * 0 <= cons < 2*X
+ * 0 <= prod < 2*X
+ * This is done because addition modulo X breaks at 2^32 when X is not a
+ * power of 2:
+ * (((2^32 - 1) % X) + 1) % X != (2^32) % X
+ */
+ uint32_t cons; /* Offset of next item to be consumed by control tools. */
+ uint32_t prod; /* Offset of next item to be produced by Xen. */
+ /* Records follow immediately after the meta-data header. */
+};
+
+/* Structure used to pass MFNs to the trace buffers back to trace consumers.
+ * Offset is an offset into the mapped structure where the mfn list will be held.
+ * MFNs will be at ((unsigned long *)(t_info))+(t_info->cpu_offset[cpu]).
+ */
+struct t_info {
+ uint16_t tbuf_size; /* Size in pages of each trace buffer */
+ uint16_t mfn_offset[]; /* Offset within t_info structure of the page list per cpu */
+ /* MFN lists immediately after the header */
+};
+
+#endif /* __XEN_PUBLIC_TRACE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 6c9e42b2b..308109f17 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -53,17 +53,22 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t);
DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
-/* Turn a plain number into a C unsigned (long) constant. */
+/* Turn a plain number into a C unsigned (long (long)) constant. */
#define __xen_mk_uint(x) x ## U
#define __xen_mk_ulong(x) x ## UL
+#ifndef __xen_mk_ullong
+# define __xen_mk_ullong(x) x ## ULL
+#endif
#define xen_mk_uint(x) __xen_mk_uint(x)
#define xen_mk_ulong(x) __xen_mk_ulong(x)
+#define xen_mk_ullong(x) __xen_mk_ullong(x)
#else
/* In assembly code we cannot use C numeric constant suffixes. */
-#define xen_mk_uint(x) x
-#define xen_mk_ulong(x) x
+#define xen_mk_uint(x) x
+#define xen_mk_ulong(x) x
+#define xen_mk_ullong(x) x
#endif
@@ -115,6 +120,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
#define __HYPERVISOR_tmem_op 38
#define __HYPERVISOR_xc_reserved_op 39 /* reserved for XenClient */
#define __HYPERVISOR_xenpmu_op 40
+#define __HYPERVISOR_dm_op 41
/* Architecture-specific hypercall definitions. */
#define __HYPERVISOR_arch_0 48
@@ -501,6 +507,21 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
/* x86/PAE guests: support PDPTs above 4GB. */
#define VMASST_TYPE_pae_extended_cr3 3
+/*
+ * x86 guests: Sane behaviour for virtual iopl
+ * - virtual iopl updated from do_iret() hypercalls.
+ * - virtual iopl reported in bounce frames.
+ * - guest kernels assumed to be level 0 for the purpose of iopl checks.
+ */
+#define VMASST_TYPE_architectural_iopl 4
+
+/*
+ * All guests: activate update indicator in vcpu_runstate_info
+ * Enable setting the XEN_RUNSTATE_UPDATE flag in guest memory mapped
+ * vcpu_runstate_info during updates of the runstate information.
+ */
+#define VMASST_TYPE_runstate_update_flag 5
+
/*
* x86/64 guests: strictly hide M2P from user mode.
* This allows the guest to control respective hypervisor behavior:
@@ -529,16 +550,21 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
* is useful to ensure that no mappings to the OS's own heap are accidentally
* installed. (e.g., in Linux this could cause havoc as reference counts
* aren't adjusted on the I/O-mapping code path).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, but in that context can
- * be specified by any calling domain.
+ * This only makes sense as HYPERVISOR_mmu_update()'s and
+ * HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument. For
+ * HYPERVISOR_mmu_update() context it can be specified by any calling domain,
+ * otherwise it's only permitted if the caller is privileged.
*/
#define DOMID_IO xen_mk_uint(0x7FF1)
/*
* DOMID_XEN is used to allow privileged domains to map restricted parts of
* Xen's heap space (e.g., the machine_to_phys table).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, and is only permitted if
- * the caller is privileged.
+ * This only makes sense as
+ * - HYPERVISOR_mmu_update()'s, HYPERVISOR_mmuext_op()'s, or
+ * HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument,
+ * - with XENMAPSPACE_gmfn_foreign,
+ * and is only permitted if the caller is privileged.
*/
#define DOMID_XEN xen_mk_uint(0x7FF2)
@@ -614,10 +640,18 @@ struct vcpu_time_info {
*/
uint32_t tsc_to_system_mul;
int8_t tsc_shift;
+#if __XEN_INTERFACE_VERSION__ > 0x040600
+ uint8_t flags;
+ uint8_t pad1[2];
+#else
int8_t pad1[3];
+#endif
}; /* 32 bytes */
typedef struct vcpu_time_info vcpu_time_info_t;
+#define XEN_PVCLOCK_TSC_STABLE_BIT (1 << 0)
+#define XEN_PVCLOCK_GUEST_STOPPED (1 << 1)
+
struct vcpu_info {
/*
* 'evtchn_upcall_pending' is written non-zero by Xen to indicate
@@ -736,7 +770,7 @@ typedef struct shared_info shared_info_t;
* (may be omitted)
* c. list of allocated page frames [mfn_list, nr_pages]
* (unless relocated due to XEN_ELFNOTE_INIT_P2M)
- * d. start_info_t structure [register ESI (x86)]
+ * d. start_info_t structure [register rSI (x86)]
* in case of dom0 this page contains the console info, too
* e. unless dom0: xenstore ring page
* f. unless dom0: console ring page
@@ -797,29 +831,6 @@ struct start_info {
};
typedef struct start_info start_info_t;
-/*
- * Start of day structure passed to PVH 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.
- */
-struct hvm_start_info {
-#define HVM_START_MAGIC_VALUE 0x336ec578
- uint32_t magic; /* Contains the magic value 0x336ec578 */
- /* ("xEn3" with the 0x80 bit of the "E" set).*/
- uint32_t flags; /* SIF_xxx flags. */
- uint32_t cmdline_paddr; /* Physical address of the command line. */
- uint32_t nr_modules; /* Number of modules passed to the kernel. */
- uint32_t modlist_paddr; /* Physical address of an array of */
- /* hvm_modlist_entry. */
-};
-
-struct hvm_modlist_entry {
- uint32_t paddr; /* Physical address of the module. */
- uint32_t size; /* Size of the module in bytes. */
-};
-
/* New console union for dom0 introduced in 0x00030203. */
#if __XEN_INTERFACE_VERSION__ < 0x00030203
#define console_mfn console.domU.mfn
@@ -919,6 +930,37 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
__DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
+typedef struct {
+ uint8_t a[16];
+} xen_uuid_t;
+
+/*
+ * XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
+ * 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
+ * will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
+ * {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
+ * 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff};
+ *
+ * NB: This is compatible with Linux kernel and with libuuid, but it is not
+ * compatible with Microsoft, as they use mixed-endian encoding (some
+ * components are little-endian, some are big-endian).
+ */
+#define XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) \
+ {{((a) >> 24) & 0xFF, ((a) >> 16) & 0xFF, \
+ ((a) >> 8) & 0xFF, ((a) >> 0) & 0xFF, \
+ ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \
+ ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, \
+ ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, \
+ e1, e2, e3, e4, e5, e6}}
+
+#if defined(__STDC_VERSION__) ? __STDC_VERSION__ >= 199901L : defined(__GNUC__)
+#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
+ ((xen_uuid_t)XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6))
+#else
+#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
+ XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)
+#endif /* __STDC_VERSION__ / __GNUC__ */
+
#endif /* !__ASSEMBLY__ */
/* Default definitions for macros used by domctl/sysctl. */
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 01/18] xen: add some xen headers
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
In order to support grub2 in Xen PVH environment some additional Xen
headers are needed as grub2 will be started in PVH mode requiring to
use several HVM hypercalls and structures.
Add the needed headers from Xen 4.10 being the first Xen version with
full (not only experimental) PVH guest support.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: update commit message (Daniel Kiper)
---
include/xen/hvm/hvm_op.h | 296 +++++++++++++++++++
include/xen/hvm/params.h | 284 ++++++++++++++++++
include/xen/hvm/start_info.h | 98 +++++++
include/xen/memory.h | 665 +++++++++++++++++++++++++++++++++++++++++++
include/xen/physdev.h | 387 +++++++++++++++++++++++++
include/xen/trace.h | 339 ++++++++++++++++++++++
include/xen/xen.h | 104 +++++--
7 files changed, 2142 insertions(+), 31 deletions(-)
create mode 100644 include/xen/hvm/hvm_op.h
create mode 100644 include/xen/hvm/params.h
create mode 100644 include/xen/hvm/start_info.h
create mode 100644 include/xen/memory.h
create mode 100644 include/xen/physdev.h
create mode 100644 include/xen/trace.h
diff --git a/include/xen/hvm/hvm_op.h b/include/xen/hvm/hvm_op.h
new file mode 100644
index 000000000..0bdafdf59
--- /dev/null
+++ b/include/xen/hvm/hvm_op.h
@@ -0,0 +1,296 @@
+/*
+ * 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) 2007, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_HVM_HVM_OP_H__
+#define __XEN_PUBLIC_HVM_HVM_OP_H__
+
+#include "../xen.h"
+#include "../trace.h"
+#include "../event_channel.h"
+
+/* Get/set subcommands: extra argument == pointer to xen_hvm_param struct. */
+#define HVMOP_set_param 0
+#define HVMOP_get_param 1
+struct xen_hvm_param {
+ domid_t domid; /* IN */
+ uint32_t index; /* IN */
+ uint64_t value; /* IN/OUT */
+};
+typedef struct xen_hvm_param xen_hvm_param_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_param_t);
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040900
+
+/* Set the logical level of one of a domain's PCI INTx wires. */
+#define HVMOP_set_pci_intx_level 2
+struct xen_hvm_set_pci_intx_level {
+ /* Domain to be updated. */
+ domid_t domid;
+ /* PCI INTx identification in PCI topology (domain:bus:device:intx). */
+ uint8_t domain, bus, device, intx;
+ /* Assertion level (0 = unasserted, 1 = asserted). */
+ uint8_t level;
+};
+typedef struct xen_hvm_set_pci_intx_level xen_hvm_set_pci_intx_level_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_pci_intx_level_t);
+
+/* Set the logical level of one of a domain's ISA IRQ wires. */
+#define HVMOP_set_isa_irq_level 3
+struct xen_hvm_set_isa_irq_level {
+ /* Domain to be updated. */
+ domid_t domid;
+ /* ISA device identification, by ISA IRQ (0-15). */
+ uint8_t isa_irq;
+ /* Assertion level (0 = unasserted, 1 = asserted). */
+ uint8_t level;
+};
+typedef struct xen_hvm_set_isa_irq_level xen_hvm_set_isa_irq_level_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_isa_irq_level_t);
+
+#define HVMOP_set_pci_link_route 4
+struct xen_hvm_set_pci_link_route {
+ /* Domain to be updated. */
+ domid_t domid;
+ /* PCI link identifier (0-3). */
+ uint8_t link;
+ /* ISA IRQ (1-15), or 0 (disable link). */
+ uint8_t isa_irq;
+};
+typedef struct xen_hvm_set_pci_link_route xen_hvm_set_pci_link_route_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t);
+
+#endif /* __XEN_INTERFACE_VERSION__ < 0x00040900 */
+
+/* Flushes all VCPU TLBs: @arg must be NULL. */
+#define HVMOP_flush_tlbs 5
+
+typedef enum {
+ HVMMEM_ram_rw, /* Normal read/write guest RAM */
+ HVMMEM_ram_ro, /* Read-only; writes are discarded */
+ HVMMEM_mmio_dm, /* Reads and write go to the device model */
+#if __XEN_INTERFACE_VERSION__ < 0x00040700
+ HVMMEM_mmio_write_dm, /* Read-only; writes go to the device model */
+#else
+ HVMMEM_unused, /* Placeholder; setting memory to this type
+ will fail for code after 4.7.0 */
+#endif
+ HVMMEM_ioreq_server /* Memory type claimed by an ioreq server; type
+ changes to this value are only allowed after
+ an ioreq server has claimed its ownership.
+ Only pages with HVMMEM_ram_rw are allowed to
+ change to this type; conversely, pages with
+ this type are only allowed to be changed back
+ to HVMMEM_ram_rw. */
+} hvmmem_type_t;
+
+/* Hint from PV drivers for pagetable destruction. */
+#define HVMOP_pagetable_dying 9
+struct xen_hvm_pagetable_dying {
+ /* Domain with a pagetable about to be destroyed. */
+ domid_t domid;
+ uint16_t pad[3]; /* align next field on 8-byte boundary */
+ /* guest physical address of the toplevel pagetable dying */
+ uint64_t gpa;
+};
+typedef struct xen_hvm_pagetable_dying xen_hvm_pagetable_dying_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_pagetable_dying_t);
+
+/* Get the current Xen time, in nanoseconds since system boot. */
+#define HVMOP_get_time 10
+struct xen_hvm_get_time {
+ uint64_t now; /* OUT */
+};
+typedef struct xen_hvm_get_time xen_hvm_get_time_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_get_time_t);
+
+#define HVMOP_xentrace 11
+struct xen_hvm_xentrace {
+ uint16_t event, extra_bytes;
+ uint8_t extra[TRACE_EXTRA_MAX * sizeof(uint32_t)];
+};
+typedef struct xen_hvm_xentrace xen_hvm_xentrace_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_xentrace_t);
+
+/* Following tools-only interfaces may change in future. */
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+/* Deprecated by XENMEM_access_op_set_access */
+#define HVMOP_set_mem_access 12
+
+/* Deprecated by XENMEM_access_op_get_access */
+#define HVMOP_get_mem_access 13
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
+#define HVMOP_get_mem_type 15
+/* Return hvmmem_type_t for the specified pfn. */
+struct xen_hvm_get_mem_type {
+ /* Domain to be queried. */
+ domid_t domid;
+ /* OUT variable. */
+ uint16_t mem_type;
+ uint16_t pad[2]; /* align next field on 8-byte boundary */
+ /* IN variable. */
+ uint64_t pfn;
+};
+typedef struct xen_hvm_get_mem_type xen_hvm_get_mem_type_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_get_mem_type_t);
+
+/* Following tools-only interfaces may change in future. */
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+/*
+ * Definitions relating to DMOP_create_ioreq_server. (Defined here for
+ * backwards compatibility).
+ */
+
+#define HVM_IOREQSRV_BUFIOREQ_OFF 0
+#define HVM_IOREQSRV_BUFIOREQ_LEGACY 1
+/*
+ * Use this when read_pointer gets updated atomically and
+ * the pointer pair gets read atomically:
+ */
+#define HVM_IOREQSRV_BUFIOREQ_ATOMIC 2
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for event
+ * channel upcalls on the specified <vcpu>. If set,
+ * this vector will be used in preference to the
+ * domain global callback via (see
+ * HVM_PARAM_CALLBACK_IRQ).
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_evtchn_upcall_vector {
+ uint32_t vcpu;
+ uint8_t vector;
+};
+typedef struct xen_hvm_evtchn_upcall_vector xen_hvm_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_evtchn_upcall_vector_t);
+
+#endif /* defined(__i386__) || defined(__x86_64__) */
+
+#define HVMOP_guest_request_vm_event 24
+
+/* HVMOP_altp2m: perform altp2m state operations */
+#define HVMOP_altp2m 25
+
+#define HVMOP_ALTP2M_INTERFACE_VERSION 0x00000001
+
+struct xen_hvm_altp2m_domain_state {
+ /* IN or OUT variable on/off */
+ uint8_t state;
+};
+typedef struct xen_hvm_altp2m_domain_state xen_hvm_altp2m_domain_state_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_domain_state_t);
+
+struct xen_hvm_altp2m_vcpu_enable_notify {
+ uint32_t vcpu_id;
+ uint32_t pad;
+ /* #VE info area gfn */
+ uint64_t gfn;
+};
+typedef struct xen_hvm_altp2m_vcpu_enable_notify xen_hvm_altp2m_vcpu_enable_notify_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_vcpu_enable_notify_t);
+
+struct xen_hvm_altp2m_view {
+ /* IN/OUT variable */
+ uint16_t view;
+ /* Create view only: default access type
+ * NOTE: currently ignored */
+ uint16_t hvmmem_default_access; /* xenmem_access_t */
+};
+typedef struct xen_hvm_altp2m_view xen_hvm_altp2m_view_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_view_t);
+
+struct xen_hvm_altp2m_set_mem_access {
+ /* view */
+ uint16_t view;
+ /* Memory type */
+ uint16_t hvmmem_access; /* xenmem_access_t */
+ uint32_t pad;
+ /* gfn */
+ uint64_t gfn;
+};
+typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
+
+struct xen_hvm_altp2m_change_gfn {
+ /* view */
+ uint16_t view;
+ uint16_t pad1;
+ uint32_t pad2;
+ /* old gfn */
+ uint64_t old_gfn;
+ /* new gfn, INVALID_GFN (~0UL) means revert */
+ uint64_t new_gfn;
+};
+typedef struct xen_hvm_altp2m_change_gfn xen_hvm_altp2m_change_gfn_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_change_gfn_t);
+
+struct xen_hvm_altp2m_op {
+ uint32_t version; /* HVMOP_ALTP2M_INTERFACE_VERSION */
+ uint32_t cmd;
+/* Get/set the altp2m state for a domain */
+#define HVMOP_altp2m_get_domain_state 1
+#define HVMOP_altp2m_set_domain_state 2
+/* Set the current VCPU to receive altp2m event notifications */
+#define HVMOP_altp2m_vcpu_enable_notify 3
+/* Create a new view */
+#define HVMOP_altp2m_create_p2m 4
+/* Destroy a view */
+#define HVMOP_altp2m_destroy_p2m 5
+/* Switch view for an entire domain */
+#define HVMOP_altp2m_switch_p2m 6
+/* Notify that a page of memory is to have specific access types */
+#define HVMOP_altp2m_set_mem_access 7
+/* Change a p2m entry to have a different gfn->mfn mapping */
+#define HVMOP_altp2m_change_gfn 8
+ domid_t domain;
+ uint16_t pad1;
+ uint32_t pad2;
+ union {
+ struct xen_hvm_altp2m_domain_state domain_state;
+ struct xen_hvm_altp2m_vcpu_enable_notify enable_notify;
+ struct xen_hvm_altp2m_view view;
+ struct xen_hvm_altp2m_set_mem_access set_mem_access;
+ struct xen_hvm_altp2m_change_gfn change_gfn;
+ uint8_t pad[64];
+ } u;
+};
+typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t);
+
+#endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/hvm/params.h b/include/xen/hvm/params.h
new file mode 100644
index 000000000..2ec2e7c80
--- /dev/null
+++ b/include/xen/hvm/params.h
@@ -0,0 +1,284 @@
+/*
+ * 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) 2007, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_HVM_PARAMS_H__
+#define __XEN_PUBLIC_HVM_PARAMS_H__
+
+#include "hvm_op.h"
+
+/*
+ * Parameter space for HVMOP_{set,get}_param.
+ */
+
+#define HVM_PARAM_CALLBACK_IRQ 0
+#define HVM_PARAM_CALLBACK_IRQ_TYPE_MASK xen_mk_ullong(0xFF00000000000000)
+/*
+ * How should CPU0 event-channel notifications be delivered?
+ *
+ * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI 0
+/*
+ * val[55:0] is a delivery GSI. GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#if defined(__i386__) || defined(__x86_64__)
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2
+/*
+ * val[7:0] is a vector number. Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
+ */
+#elif defined(__arm__) || defined(__aarch64__)
+#define HVM_PARAM_CALLBACK_TYPE_PPI 2
+/*
+ * val[55:16] needs to be zero.
+ * val[15:8] is interrupt flag of the PPI used by event-channel:
+ * bit 8: the PPI is edge(1) or level(0) triggered
+ * bit 9: the PPI is active low(1) or high(0)
+ * val[7:0] is a PPI number used by event-channel.
+ * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
+ * the notification is handled by the interrupt controller.
+ */
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK 0xFF00
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
+#endif
+
+/*
+ * These are not used by Xen. They are here for convenience of HVM-guest
+ * xenbus implementations.
+ */
+#define HVM_PARAM_STORE_PFN 1
+#define HVM_PARAM_STORE_EVTCHN 2
+
+#define HVM_PARAM_PAE_ENABLED 4
+
+#define HVM_PARAM_IOREQ_PFN 5
+
+#define HVM_PARAM_BUFIOREQ_PFN 6
+#define HVM_PARAM_BUFIOREQ_EVTCHN 26
+
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * Viridian enlightenments
+ *
+ * (See http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor%20Top%20Level%20Functional%20Specification%20v4.0.docx)
+ *
+ * To expose viridian enlightenments to the guest set this parameter
+ * to the desired feature mask. The base feature set must be present
+ * in any valid feature mask.
+ */
+#define HVM_PARAM_VIRIDIAN 9
+
+/* Base+Freq viridian feature sets:
+ *
+ * - Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL)
+ * - APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR)
+ * - Virtual Processor index MSR (HV_X64_MSR_VP_INDEX)
+ * - Timer frequency MSRs (HV_X64_MSR_TSC_FREQUENCY and
+ * HV_X64_MSR_APIC_FREQUENCY)
+ */
+#define _HVMPV_base_freq 0
+#define HVMPV_base_freq (1 << _HVMPV_base_freq)
+
+/* Feature set modifications */
+
+/* Disable timer frequency MSRs (HV_X64_MSR_TSC_FREQUENCY and
+ * HV_X64_MSR_APIC_FREQUENCY).
+ * This modification restores the viridian feature set to the
+ * original 'base' set exposed in releases prior to Xen 4.4.
+ */
+#define _HVMPV_no_freq 1
+#define HVMPV_no_freq (1 << _HVMPV_no_freq)
+
+/* Enable Partition Time Reference Counter (HV_X64_MSR_TIME_REF_COUNT) */
+#define _HVMPV_time_ref_count 2
+#define HVMPV_time_ref_count (1 << _HVMPV_time_ref_count)
+
+/* Enable Reference TSC Page (HV_X64_MSR_REFERENCE_TSC) */
+#define _HVMPV_reference_tsc 3
+#define HVMPV_reference_tsc (1 << _HVMPV_reference_tsc)
+
+/* Use Hypercall for remote TLB flush */
+#define _HVMPV_hcall_remote_tlb_flush 4
+#define HVMPV_hcall_remote_tlb_flush (1 << _HVMPV_hcall_remote_tlb_flush)
+
+/* Use APIC assist */
+#define _HVMPV_apic_assist 5
+#define HVMPV_apic_assist (1 << _HVMPV_apic_assist)
+
+/* Enable crash MSRs */
+#define _HVMPV_crash_ctl 6
+#define HVMPV_crash_ctl (1 << _HVMPV_crash_ctl)
+
+#define HVMPV_feature_mask \
+ (HVMPV_base_freq | \
+ HVMPV_no_freq | \
+ HVMPV_time_ref_count | \
+ HVMPV_reference_tsc | \
+ HVMPV_hcall_remote_tlb_flush | \
+ HVMPV_apic_assist | \
+ HVMPV_crash_ctl)
+
+#endif
+
+/*
+ * Set mode for virtual timers (currently x86 only):
+ * delay_for_missed_ticks (default):
+ * Do not advance a vcpu's time beyond the correct delivery time for
+ * interrupts that have been missed due to preemption. Deliver missed
+ * interrupts when the vcpu is rescheduled and advance the vcpu's virtual
+ * time stepwise for each one.
+ * no_delay_for_missed_ticks:
+ * As above, missed interrupts are delivered, but guest time always tracks
+ * wallclock (i.e., real) time while doing so.
+ * no_missed_ticks_pending:
+ * No missed interrupts are held pending. Instead, to ensure ticks are
+ * delivered at some non-zero rate, if we detect missed ticks then the
+ * internal tick alarm is not disabled if the VCPU is preempted during the
+ * next tick period.
+ * one_missed_tick_pending:
+ * Missed interrupts are collapsed together and delivered as one 'late tick'.
+ * Guest time always tracks wallclock (i.e., real) time.
+ */
+#define HVM_PARAM_TIMER_MODE 10
+#define HVMPTM_delay_for_missed_ticks 0
+#define HVMPTM_no_delay_for_missed_ticks 1
+#define HVMPTM_no_missed_ticks_pending 2
+#define HVMPTM_one_missed_tick_pending 3
+
+/* Boolean: Enable virtual HPET (high-precision event timer)? (x86-only) */
+#define HVM_PARAM_HPET_ENABLED 11
+
+/* Identity-map page directory used by Intel EPT when CR0.PG=0. */
+#define HVM_PARAM_IDENT_PT 12
+
+/* Device Model domain, defaults to 0. */
+#define HVM_PARAM_DM_DOMAIN 13
+
+/* ACPI S state: currently support S0 and S3 on x86. */
+#define HVM_PARAM_ACPI_S_STATE 14
+
+/* TSS used on Intel when CR0.PE=0. */
+#define HVM_PARAM_VM86_TSS 15
+
+/* Boolean: Enable aligning all periodic vpts to reduce interrupts */
+#define HVM_PARAM_VPT_ALIGN 16
+
+/* Console debug shared memory ring and event channel */
+#define HVM_PARAM_CONSOLE_PFN 17
+#define HVM_PARAM_CONSOLE_EVTCHN 18
+
+/*
+ * Select location of ACPI PM1a and TMR control blocks. Currently two locations
+ * are supported, specified by version 0 or 1 in this parameter:
+ * - 0: default, use the old addresses
+ * PM1A_EVT == 0x1f40; PM1A_CNT == 0x1f44; PM_TMR == 0x1f48
+ * - 1: use the new default qemu addresses
+ * PM1A_EVT == 0xb000; PM1A_CNT == 0xb004; PM_TMR == 0xb008
+ * You can find these address definitions in <hvm/ioreq.h>
+ */
+#define HVM_PARAM_ACPI_IOPORTS_LOCATION 19
+
+/* Deprecated */
+#define HVM_PARAM_MEMORY_EVENT_CR0 20
+#define HVM_PARAM_MEMORY_EVENT_CR3 21
+#define HVM_PARAM_MEMORY_EVENT_CR4 22
+#define HVM_PARAM_MEMORY_EVENT_INT3 23
+#define HVM_PARAM_MEMORY_EVENT_SINGLE_STEP 25
+#define HVM_PARAM_MEMORY_EVENT_MSR 30
+
+/* Boolean: Enable nestedhvm (hvm only) */
+#define HVM_PARAM_NESTEDHVM 24
+
+/* Params for the mem event rings */
+#define HVM_PARAM_PAGING_RING_PFN 27
+#define HVM_PARAM_MONITOR_RING_PFN 28
+#define HVM_PARAM_SHARING_RING_PFN 29
+
+/* SHUTDOWN_* action in case of a triple fault */
+#define HVM_PARAM_TRIPLE_FAULT_REASON 31
+
+#define HVM_PARAM_IOREQ_SERVER_PFN 32
+#define HVM_PARAM_NR_IOREQ_SERVER_PAGES 33
+
+/* Location of the VM Generation ID in guest physical address space. */
+#define HVM_PARAM_VM_GENERATION_ID_ADDR 34
+
+/*
+ * Set mode for altp2m:
+ * disabled: don't activate altp2m (default)
+ * mixed: allow access to all altp2m ops for both in-guest and external tools
+ * external: allow access to external privileged tools only
+ * limited: guest only has limited access (ie. control VMFUNC and #VE)
+ */
+#define HVM_PARAM_ALTP2M 35
+#define XEN_ALTP2M_disabled 0
+#define XEN_ALTP2M_mixed 1
+#define XEN_ALTP2M_external 2
+#define XEN_ALTP2M_limited 3
+
+/*
+ * Size of the x87 FPU FIP/FDP registers that the hypervisor needs to
+ * save/restore. This is a workaround for a hardware limitation that
+ * does not allow the full FIP/FDP and FCS/FDS to be restored.
+ *
+ * Valid values are:
+ *
+ * 8: save/restore 64-bit FIP/FDP and clear FCS/FDS (default if CPU
+ * has FPCSDS feature).
+ *
+ * 4: save/restore 32-bit FIP/FDP, FCS/FDS, and clear upper 32-bits of
+ * FIP/FDP.
+ *
+ * 0: allow hypervisor to choose based on the value of FIP/FDP
+ * (default if CPU does not have FPCSDS).
+ *
+ * If FPCSDS (bit 13 in CPUID leaf 0x7, subleaf 0x0) is set, the CPU
+ * never saves FCS/FDS and this parameter should be left at the
+ * default of 8.
+ */
+#define HVM_PARAM_X87_FIP_WIDTH 36
+
+/*
+ * TSS (and its size) used on Intel when CR0.PE=0. The address occupies
+ * the low 32 bits, while the size is in the high 32 ones.
+ */
+#define HVM_PARAM_VM86_TSS_SIZED 37
+
+/* Enable MCA capabilities. */
+#define HVM_PARAM_MCA_CAP 38
+#define XEN_HVM_MCA_CAP_LMCE (xen_mk_ullong(1) << 0)
+#define XEN_HVM_MCA_CAP_MASK XEN_HVM_MCA_CAP_LMCE
+
+#define HVM_NR_PARAMS 39
+
+#endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
diff --git a/include/xen/hvm/start_info.h b/include/xen/hvm/start_info.h
new file mode 100644
index 000000000..648415976
--- /dev/null
+++ b/include/xen/hvm/start_info.h
@@ -0,0 +1,98 @@
+/*
+ * 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 0. 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 +----------------+
+ *
+ * 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 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.
+ */
+#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. */
+};
+
+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;
+};
+
+#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
diff --git a/include/xen/memory.h b/include/xen/memory.h
new file mode 100644
index 000000000..29386df98
--- /dev/null
+++ b/include/xen/memory.h
@@ -0,0 +1,665 @@
+/******************************************************************************
+ * memory.h
+ *
+ * Memory reservation and information.
+ *
+ * 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) 2005, Keir Fraser <keir@xensource.com>
+ */
+
+#ifndef __XEN_PUBLIC_MEMORY_H__
+#define __XEN_PUBLIC_MEMORY_H__
+
+#include "xen.h"
+#include "physdev.h"
+
+/*
+ * Increase or decrease the specified domain's memory reservation. Returns the
+ * number of extents successfully allocated or freed.
+ * arg == addr of struct xen_memory_reservation.
+ */
+#define XENMEM_increase_reservation 0
+#define XENMEM_decrease_reservation 1
+#define XENMEM_populate_physmap 6
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00030209
+/*
+ * Maximum # bits addressable by the user of the allocated region (e.g., I/O
+ * devices often have a 32-bit limitation even in 64-bit systems). If zero
+ * then the user has no addressing restriction. This field is not used by
+ * XENMEM_decrease_reservation.
+ */
+#define XENMEMF_address_bits(x) (x)
+#define XENMEMF_get_address_bits(x) ((x) & 0xffu)
+/* NUMA node to allocate from. */
+#define XENMEMF_node(x) (((x) + 1) << 8)
+#define XENMEMF_get_node(x) ((((x) >> 8) - 1) & 0xffu)
+/* Flag to populate physmap with populate-on-demand entries */
+#define XENMEMF_populate_on_demand (1<<16)
+/* Flag to request allocation only from the node specified */
+#define XENMEMF_exact_node_request (1<<17)
+#define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request)
+/* Flag to indicate the node specified is virtual node */
+#define XENMEMF_vnode (1<<18)
+#endif
+
+struct xen_memory_reservation {
+
+ /*
+ * XENMEM_increase_reservation:
+ * OUT: MFN (*not* GMFN) bases of extents that were allocated
+ * XENMEM_decrease_reservation:
+ * IN: GMFN bases of extents to free
+ * XENMEM_populate_physmap:
+ * IN: GPFN bases of extents to populate with memory
+ * OUT: GMFN bases of extents that were allocated
+ * (NB. This command also updates the mach_to_phys translation table)
+ * XENMEM_claim_pages:
+ * IN: must be zero
+ */
+ XEN_GUEST_HANDLE(xen_pfn_t) extent_start;
+
+ /* Number of extents, and size/alignment of each (2^extent_order pages). */
+ xen_ulong_t nr_extents;
+ unsigned int extent_order;
+
+#if __XEN_INTERFACE_VERSION__ >= 0x00030209
+ /* XENMEMF flags. */
+ unsigned int mem_flags;
+#else
+ unsigned int address_bits;
+#endif
+
+ /*
+ * Domain whose reservation is being changed.
+ * Unprivileged domains can specify only DOMID_SELF.
+ */
+ domid_t domid;
+};
+typedef struct xen_memory_reservation xen_memory_reservation_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_reservation_t);
+
+/*
+ * An atomic exchange of memory pages. If return code is zero then
+ * @out.extent_list provides GMFNs of the newly-allocated memory.
+ * Returns zero on complete success, otherwise a negative error code.
+ * On complete success then always @nr_exchanged == @in.nr_extents.
+ * On partial success @nr_exchanged indicates how much work was done.
+ *
+ * Note that only PV guests can use this operation.
+ */
+#define XENMEM_exchange 11
+struct xen_memory_exchange {
+ /*
+ * [IN] Details of memory extents to be exchanged (GMFN bases).
+ * Note that @in.address_bits is ignored and unused.
+ */
+ struct xen_memory_reservation in;
+
+ /*
+ * [IN/OUT] Details of new memory extents.
+ * We require that:
+ * 1. @in.domid == @out.domid
+ * 2. @in.nr_extents << @in.extent_order ==
+ * @out.nr_extents << @out.extent_order
+ * 3. @in.extent_start and @out.extent_start lists must not overlap
+ * 4. @out.extent_start lists GPFN bases to be populated
+ * 5. @out.extent_start is overwritten with allocated GMFN bases
+ */
+ struct xen_memory_reservation out;
+
+ /*
+ * [OUT] Number of input extents that were successfully exchanged:
+ * 1. The first @nr_exchanged input extents were successfully
+ * deallocated.
+ * 2. The corresponding first entries in the output extent list correctly
+ * indicate the GMFNs that were successfully exchanged.
+ * 3. All other input and output extents are untouched.
+ * 4. If not all input exents are exchanged then the return code of this
+ * command will be non-zero.
+ * 5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
+ */
+ xen_ulong_t nr_exchanged;
+};
+typedef struct xen_memory_exchange xen_memory_exchange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_exchange_t);
+
+/*
+ * Returns the maximum machine frame number of mapped RAM in this system.
+ * This command always succeeds (it never returns an error code).
+ * arg == NULL.
+ */
+#define XENMEM_maximum_ram_page 2
+
+/*
+ * Returns the current or maximum memory reservation, in pages, of the
+ * specified domain (may be DOMID_SELF). Returns -ve errcode on failure.
+ * arg == addr of domid_t.
+ */
+#define XENMEM_current_reservation 3
+#define XENMEM_maximum_reservation 4
+
+/*
+ * Returns the maximum GPFN in use by the guest, or -ve errcode on failure.
+ */
+#define XENMEM_maximum_gpfn 14
+
+/*
+ * Returns a list of MFN bases of 2MB extents comprising the machine_to_phys
+ * mapping table. Architectures which do not have a m2p table do not implement
+ * this command.
+ * arg == addr of xen_machphys_mfn_list_t.
+ */
+#define XENMEM_machphys_mfn_list 5
+struct xen_machphys_mfn_list {
+ /*
+ * Size of the 'extent_start' array. Fewer entries will be filled if the
+ * machphys table is smaller than max_extents * 2MB.
+ */
+ unsigned int max_extents;
+
+ /*
+ * Pointer to buffer to fill with list of extent starts. If there are
+ * any large discontiguities in the machine address space, 2MB gaps in
+ * the machphys table will be represented by an MFN base of zero.
+ */
+ XEN_GUEST_HANDLE(xen_pfn_t) extent_start;
+
+ /*
+ * Number of extents written to the above array. This will be smaller
+ * than 'max_extents' if the machphys table is smaller than max_e * 2MB.
+ */
+ unsigned int nr_extents;
+};
+typedef struct xen_machphys_mfn_list xen_machphys_mfn_list_t;
+DEFINE_XEN_GUEST_HANDLE(xen_machphys_mfn_list_t);
+
+/*
+ * For a compat caller, this is identical to XENMEM_machphys_mfn_list.
+ *
+ * For a non compat caller, this functions similarly to
+ * XENMEM_machphys_mfn_list, but returns the mfns making up the compatibility
+ * m2p table.
+ */
+#define XENMEM_machphys_compat_mfn_list 25
+
+/*
+ * Returns the location in virtual address space of the machine_to_phys
+ * mapping table. Architectures which do not have a m2p table, or which do not
+ * map it by default into guest address space, do not implement this command.
+ * arg == addr of xen_machphys_mapping_t.
+ */
+#define XENMEM_machphys_mapping 12
+struct xen_machphys_mapping {
+ xen_ulong_t v_start, v_end; /* Start and end virtual addresses. */
+ xen_ulong_t max_mfn; /* Maximum MFN that can be looked up. */
+};
+typedef struct xen_machphys_mapping xen_machphys_mapping_t;
+DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
+
+/* Source mapping space. */
+/* ` enum phys_map_space { */
+#define XENMAPSPACE_shared_info 0 /* shared info page */
+#define XENMAPSPACE_grant_table 1 /* grant table page */
+#define XENMAPSPACE_gmfn 2 /* GMFN */
+#define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap only. */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+ * XENMEM_add_to_physmap_batch only. */
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region
+ ARM only; the region is mapped in
+ Stage-2 using the Normal Memory
+ Inner/Outer Write-Back Cacheable
+ memory attribute. */
+/* ` } */
+
+/*
+ * Sets the GPFN at which a particular page appears in the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_add_to_physmap_t.
+ */
+#define XENMEM_add_to_physmap 7
+struct xen_add_to_physmap {
+ /* Which domain to change the mapping for. */
+ domid_t domid;
+
+ /* Number of pages to go through for gmfn_range */
+ uint16_t size;
+
+ unsigned int space; /* => enum phys_map_space */
+
+#define XENMAPIDX_grant_table_status 0x80000000
+
+ /* Index into space being mapped. */
+ xen_ulong_t idx;
+
+ /* GPFN in domid where the source mapping page should appear. */
+ xen_pfn_t gpfn;
+};
+typedef struct xen_add_to_physmap xen_add_to_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
+
+/* A batched version of add_to_physmap. */
+#define XENMEM_add_to_physmap_batch 23
+struct xen_add_to_physmap_batch {
+ /* IN */
+ /* Which domain to change the mapping for. */
+ domid_t domid;
+ uint16_t space; /* => enum phys_map_space */
+
+ /* Number of pages to go through */
+ uint16_t size;
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040700
+ domid_t foreign_domid; /* IFF gmfn_foreign. Should be 0 for other spaces. */
+#else
+ union xen_add_to_physmap_batch_extra {
+ domid_t foreign_domid; /* gmfn_foreign */
+ uint16_t res0; /* All the other spaces. Should be 0 */
+ } u;
+#endif
+
+ /* Indexes into space being mapped. */
+ XEN_GUEST_HANDLE(xen_ulong_t) idxs;
+
+ /* GPFN in domid where the source mapping page should appear. */
+ XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
+
+ /* OUT */
+
+ /* Per index error code. */
+ XEN_GUEST_HANDLE(int) errs;
+};
+typedef struct xen_add_to_physmap_batch xen_add_to_physmap_batch_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_batch_t);
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040400
+#define XENMEM_add_to_physmap_range XENMEM_add_to_physmap_batch
+#define xen_add_to_physmap_range xen_add_to_physmap_batch
+typedef struct xen_add_to_physmap_batch xen_add_to_physmap_range_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
+#endif
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap 15
+struct xen_remove_from_physmap {
+ /* Which domain to change the mapping for. */
+ domid_t domid;
+
+ /* GPFN of the current mapping of the page. */
+ xen_pfn_t gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
+/*** REMOVED ***/
+/*#define XENMEM_translate_gpfn_list 8*/
+
+/*
+ * Returns the pseudo-physical memory map as it was when the domain
+ * was started (specified by XENMEM_set_memory_map).
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_memory_map 9
+struct xen_memory_map {
+ /*
+ * On call the number of entries which can be stored in buffer. On
+ * return the number of entries which have been stored in
+ * buffer.
+ */
+ unsigned int nr_entries;
+
+ /*
+ * Entries in the buffer are in the same format as returned by the
+ * BIOS INT 0x15 EAX=0xE820 call.
+ */
+ XEN_GUEST_HANDLE(void) buffer;
+};
+typedef struct xen_memory_map xen_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
+
+/*
+ * Returns the real physical memory map. Passes the same structure as
+ * XENMEM_memory_map.
+ * Specifying buffer as NULL will return the number of entries required
+ * to store the complete memory map.
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_machine_memory_map 10
+
+/*
+ * Set the pseudo-physical memory map of a domain, as returned by
+ * XENMEM_memory_map.
+ * arg == addr of xen_foreign_memory_map_t.
+ */
+#define XENMEM_set_memory_map 13
+struct xen_foreign_memory_map {
+ domid_t domid;
+ struct xen_memory_map map;
+};
+typedef struct xen_foreign_memory_map xen_foreign_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_foreign_memory_map_t);
+
+#define XENMEM_set_pod_target 16
+#define XENMEM_get_pod_target 17
+struct xen_pod_target {
+ /* IN */
+ uint64_t target_pages;
+ /* OUT */
+ uint64_t tot_pages;
+ uint64_t pod_cache_pages;
+ uint64_t pod_entries;
+ /* IN */
+ domid_t domid;
+};
+typedef struct xen_pod_target xen_pod_target_t;
+
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
+/*
+ * Get the number of MFNs saved through memory sharing.
+ * The call never fails.
+ */
+#define XENMEM_get_sharing_freed_pages 18
+#define XENMEM_get_sharing_shared_pages 19
+
+#define XENMEM_paging_op 20
+#define XENMEM_paging_op_nominate 0
+#define XENMEM_paging_op_evict 1
+#define XENMEM_paging_op_prep 2
+
+struct xen_mem_paging_op {
+ uint8_t op; /* XENMEM_paging_op_* */
+ domid_t domain;
+
+ /* PAGING_PREP IN: buffer to immediately fill page in */
+ uint64_aligned_t buffer;
+ /* Other OPs */
+ uint64_aligned_t gfn; /* IN: gfn of page being operated on */
+};
+typedef struct xen_mem_paging_op xen_mem_paging_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_paging_op_t);
+
+#define XENMEM_access_op 21
+#define XENMEM_access_op_set_access 0
+#define XENMEM_access_op_get_access 1
+/*
+ * XENMEM_access_op_enable_emulate and XENMEM_access_op_disable_emulate are
+ * currently unused, but since they have been in use please do not reuse them.
+ *
+ * #define XENMEM_access_op_enable_emulate 2
+ * #define XENMEM_access_op_disable_emulate 3
+ */
+#define XENMEM_access_op_set_access_multi 4
+
+typedef enum {
+ XENMEM_access_n,
+ XENMEM_access_r,
+ XENMEM_access_w,
+ XENMEM_access_rw,
+ XENMEM_access_x,
+ XENMEM_access_rx,
+ XENMEM_access_wx,
+ XENMEM_access_rwx,
+ /*
+ * Page starts off as r-x, but automatically
+ * change to r-w on a write
+ */
+ XENMEM_access_rx2rw,
+ /*
+ * Log access: starts off as n, automatically
+ * goes to rwx, generating an event without
+ * pausing the vcpu
+ */
+ XENMEM_access_n2rwx,
+ /* Take the domain default */
+ XENMEM_access_default
+} xenmem_access_t;
+
+struct xen_mem_access_op {
+ /* XENMEM_access_op_* */
+ uint8_t op;
+ /* xenmem_access_t */
+ uint8_t access;
+ domid_t domid;
+ /*
+ * Number of pages for set op (or size of pfn_list for
+ * XENMEM_access_op_set_access_multi)
+ * Ignored on setting default access and other ops
+ */
+ uint32_t nr;
+ /*
+ * First pfn for set op
+ * pfn for get op
+ * ~0ull is used to set and get the default access for pages
+ */
+ uint64_aligned_t pfn;
+ /*
+ * List of pfns to set access for
+ * Used only with XENMEM_access_op_set_access_multi
+ */
+ XEN_GUEST_HANDLE(const_uint64) pfn_list;
+ /*
+ * Corresponding list of access settings for pfn_list
+ * Used only with XENMEM_access_op_set_access_multi
+ */
+ XEN_GUEST_HANDLE(const_uint8) access_list;
+};
+typedef struct xen_mem_access_op xen_mem_access_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_access_op_t);
+
+#define XENMEM_sharing_op 22
+#define XENMEM_sharing_op_nominate_gfn 0
+#define XENMEM_sharing_op_nominate_gref 1
+#define XENMEM_sharing_op_share 2
+#define XENMEM_sharing_op_debug_gfn 3
+#define XENMEM_sharing_op_debug_mfn 4
+#define XENMEM_sharing_op_debug_gref 5
+#define XENMEM_sharing_op_add_physmap 6
+#define XENMEM_sharing_op_audit 7
+#define XENMEM_sharing_op_range_share 8
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG (xen_mk_ullong(1) << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val) \
+ (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field) \
+ ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field) \
+ ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+ uint8_t op; /* XENMEM_sharing_op_* */
+ domid_t domain;
+
+ union {
+ struct mem_sharing_op_nominate { /* OP_NOMINATE_xxx */
+ union {
+ uint64_aligned_t gfn; /* IN: gfn to nominate */
+ uint32_t grant_ref; /* IN: grant ref to nominate */
+ } u;
+ uint64_aligned_t handle; /* OUT: the handle */
+ } nominate;
+ struct mem_sharing_op_share { /* OP_SHARE/ADD_PHYSMAP */
+ uint64_aligned_t source_gfn; /* IN: the gfn of the source page */
+ uint64_aligned_t source_handle; /* IN: handle to the source page */
+ uint64_aligned_t client_gfn; /* IN: the client gfn */
+ uint64_aligned_t client_handle; /* IN: handle to the client page */
+ domid_t client_domain; /* IN: the client domain id */
+ } share;
+ struct mem_sharing_op_range { /* OP_RANGE_SHARE */
+ uint64_aligned_t first_gfn; /* IN: the first gfn */
+ uint64_aligned_t last_gfn; /* IN: the last gfn */
+ uint64_aligned_t opaque; /* Must be set to 0 */
+ domid_t client_domain; /* IN: the client domain id */
+ uint16_t _pad[3]; /* Must be set to 0 */
+ } range;
+ struct mem_sharing_op_debug { /* OP_DEBUG_xxx */
+ union {
+ uint64_aligned_t gfn; /* IN: gfn to debug */
+ uint64_aligned_t mfn; /* IN: mfn to debug */
+ uint32_t gref; /* IN: gref to debug */
+ } u;
+ } debug;
+ } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+/*
+ * Attempt to stake a claim for a domain on a quantity of pages
+ * of system RAM, but _not_ assign specific pageframes. Only
+ * arithmetic is performed so the hypercall is very fast and need
+ * not be preemptible, thus sidestepping time-of-check-time-of-use
+ * races for memory allocation. Returns 0 if the hypervisor page
+ * allocator has atomically and successfully claimed the requested
+ * number of pages, else non-zero.
+ *
+ * Any domain may have only one active claim. When sufficient memory
+ * has been allocated to resolve the claim, the claim silently expires.
+ * Claiming zero pages effectively resets any outstanding claim and
+ * is always successful.
+ *
+ * Note that a valid claim may be staked even after memory has been
+ * allocated for a domain. In this case, the claim is not incremental,
+ * i.e. if the domain's tot_pages is 3, and a claim is staked for 10,
+ * only 7 additional pages are claimed.
+ *
+ * Caller must be privileged or the hypercall fails.
+ */
+#define XENMEM_claim_pages 24
+
+/*
+ * XENMEM_claim_pages flags - the are no flags at this time.
+ * The zero value is appropriate.
+ */
+
+/*
+ * With some legacy devices, certain guest-physical addresses cannot safely
+ * be used for other purposes, e.g. to map guest RAM. This hypercall
+ * enumerates those regions so the toolstack can avoid using them.
+ */
+#define XENMEM_reserved_device_memory_map 27
+struct xen_reserved_device_memory {
+ xen_pfn_t start_pfn;
+ xen_ulong_t nr_pages;
+};
+typedef struct xen_reserved_device_memory xen_reserved_device_memory_t;
+DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_t);
+
+struct xen_reserved_device_memory_map {
+#define XENMEM_RDM_ALL 1 /* Request all regions (ignore dev union). */
+ /* IN */
+ uint32_t flags;
+ /*
+ * IN/OUT
+ *
+ * Gets set to the required number of entries when too low,
+ * signaled by error code -ERANGE.
+ */
+ unsigned int nr_entries;
+ /* OUT */
+ XEN_GUEST_HANDLE(xen_reserved_device_memory_t) buffer;
+ /* IN */
+ union {
+ struct physdev_pci_device pci;
+ } dev;
+};
+typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
+/*
+ * XENMEM_get_vnumainfo used by guest to get
+ * vNUMA topology from hypervisor.
+ */
+#define XENMEM_get_vnumainfo 26
+
+/* vNUMA node memory ranges */
+struct xen_vmemrange {
+ uint64_t start, end;
+ unsigned int flags;
+ unsigned int nid;
+};
+typedef struct xen_vmemrange xen_vmemrange_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vmemrange_t);
+
+/*
+ * vNUMA topology specifies vNUMA node number, distance table,
+ * memory ranges and vcpu mapping provided for guests.
+ * XENMEM_get_vnumainfo hypercall expects to see from guest
+ * nr_vnodes, nr_vmemranges and nr_vcpus to indicate available memory.
+ * After filling guests structures, nr_vnodes, nr_vmemranges and nr_vcpus
+ * copied back to guest. Domain returns expected values of nr_vnodes,
+ * nr_vmemranges and nr_vcpus to guest if the values where incorrect.
+ */
+struct xen_vnuma_topology_info {
+ /* IN */
+ domid_t domid;
+ uint16_t pad;
+ /* IN/OUT */
+ unsigned int nr_vnodes;
+ unsigned int nr_vcpus;
+ unsigned int nr_vmemranges;
+ /* OUT */
+ union {
+ XEN_GUEST_HANDLE(uint) h;
+ uint64_t pad;
+ } vdistance;
+ union {
+ XEN_GUEST_HANDLE(uint) h;
+ uint64_t pad;
+ } vcpu_to_vnode;
+ union {
+ XEN_GUEST_HANDLE(xen_vmemrange_t) h;
+ uint64_t pad;
+ } vmemrange;
+};
+typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
+DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
+
+/* Next available subop number is 28 */
+
+#endif /* __XEN_PUBLIC_MEMORY_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/physdev.h b/include/xen/physdev.h
new file mode 100644
index 000000000..0e5463562
--- /dev/null
+++ b/include/xen/physdev.h
@@ -0,0 +1,387 @@
+/*
+ * 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) 2006, Keir Fraser
+ */
+
+#ifndef __XEN_PUBLIC_PHYSDEV_H__
+#define __XEN_PUBLIC_PHYSDEV_H__
+
+#include "xen.h"
+
+/*
+ * Prototype for this hypercall is:
+ * int physdev_op(int cmd, void *args)
+ * @cmd == PHYSDEVOP_??? (physdev operation).
+ * @args == Operation-specific extra arguments (NULL if none).
+ */
+
+/*
+ * Notify end-of-interrupt (EOI) for the specified IRQ.
+ * @arg == pointer to physdev_eoi structure.
+ */
+#define PHYSDEVOP_eoi 12
+struct physdev_eoi {
+ /* IN */
+ uint32_t irq;
+};
+typedef struct physdev_eoi physdev_eoi_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
+
+/*
+ * Register a shared page for the hypervisor to indicate whether the guest
+ * must issue PHYSDEVOP_eoi. The semantics of PHYSDEVOP_eoi change slightly
+ * once the guest used this function in that the associated event channel
+ * will automatically get unmasked. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v1 17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2 28
+struct physdev_pirq_eoi_gmfn {
+ /* IN */
+ xen_pfn_t gmfn;
+};
+typedef struct physdev_pirq_eoi_gmfn physdev_pirq_eoi_gmfn_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pirq_eoi_gmfn_t);
+
+/*
+ * Query the status of an IRQ line.
+ * @arg == pointer to physdev_irq_status_query structure.
+ */
+#define PHYSDEVOP_irq_status_query 5
+struct physdev_irq_status_query {
+ /* IN */
+ uint32_t irq;
+ /* OUT */
+ uint32_t flags; /* XENIRQSTAT_* */
+};
+typedef struct physdev_irq_status_query physdev_irq_status_query_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_irq_status_query_t);
+
+/* Need to call PHYSDEVOP_eoi when the IRQ has been serviced? */
+#define _XENIRQSTAT_needs_eoi (0)
+#define XENIRQSTAT_needs_eoi (1U<<_XENIRQSTAT_needs_eoi)
+
+/* IRQ shared by multiple guests? */
+#define _XENIRQSTAT_shared (1)
+#define XENIRQSTAT_shared (1U<<_XENIRQSTAT_shared)
+
+/*
+ * Set the current VCPU's I/O privilege level.
+ * @arg == pointer to physdev_set_iopl structure.
+ */
+#define PHYSDEVOP_set_iopl 6
+struct physdev_set_iopl {
+ /* IN */
+ uint32_t iopl;
+};
+typedef struct physdev_set_iopl physdev_set_iopl_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_set_iopl_t);
+
+/*
+ * Set the current VCPU's I/O-port permissions bitmap.
+ * @arg == pointer to physdev_set_iobitmap structure.
+ */
+#define PHYSDEVOP_set_iobitmap 7
+struct physdev_set_iobitmap {
+ /* IN */
+#if __XEN_INTERFACE_VERSION__ >= 0x00030205
+ XEN_GUEST_HANDLE(uint8) bitmap;
+#else
+ uint8_t *bitmap;
+#endif
+ uint32_t nr_ports;
+};
+typedef struct physdev_set_iobitmap physdev_set_iobitmap_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_set_iobitmap_t);
+
+/*
+ * Read or write an IO-APIC register.
+ * @arg == pointer to physdev_apic structure.
+ */
+#define PHYSDEVOP_apic_read 8
+#define PHYSDEVOP_apic_write 9
+struct physdev_apic {
+ /* IN */
+ unsigned long apic_physbase;
+ uint32_t reg;
+ /* IN or OUT */
+ uint32_t value;
+};
+typedef struct physdev_apic physdev_apic_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_apic_t);
+
+/*
+ * Allocate or free a physical upcall vector for the specified IRQ line.
+ * @arg == pointer to physdev_irq structure.
+ */
+#define PHYSDEVOP_alloc_irq_vector 10
+#define PHYSDEVOP_free_irq_vector 11
+struct physdev_irq {
+ /* IN */
+ uint32_t irq;
+ /* IN or OUT */
+ uint32_t vector;
+};
+typedef struct physdev_irq physdev_irq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_irq_t);
+
+#define MAP_PIRQ_TYPE_MSI 0x0
+#define MAP_PIRQ_TYPE_GSI 0x1
+#define MAP_PIRQ_TYPE_UNKNOWN 0x2
+#define MAP_PIRQ_TYPE_MSI_SEG 0x3
+#define MAP_PIRQ_TYPE_MULTI_MSI 0x4
+
+#define PHYSDEVOP_map_pirq 13
+struct physdev_map_pirq {
+ domid_t domid;
+ /* IN */
+ int type;
+ /* IN (ignored for ..._MULTI_MSI) */
+ int index;
+ /* IN or OUT */
+ int pirq;
+ /* IN - high 16 bits hold segment for ..._MSI_SEG and ..._MULTI_MSI */
+ int bus;
+ /* IN */
+ int devfn;
+ /* IN (also OUT for ..._MULTI_MSI) */
+ int entry_nr;
+ /* IN */
+ uint64_t table_base;
+};
+typedef struct physdev_map_pirq physdev_map_pirq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_map_pirq_t);
+
+#define PHYSDEVOP_unmap_pirq 14
+struct physdev_unmap_pirq {
+ domid_t domid;
+ /* IN */
+ int pirq;
+};
+
+typedef struct physdev_unmap_pirq physdev_unmap_pirq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_unmap_pirq_t);
+
+#define PHYSDEVOP_manage_pci_add 15
+#define PHYSDEVOP_manage_pci_remove 16
+struct physdev_manage_pci {
+ /* IN */
+ uint8_t bus;
+ uint8_t devfn;
+};
+
+typedef struct physdev_manage_pci physdev_manage_pci_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_manage_pci_t);
+
+#define PHYSDEVOP_restore_msi 19
+struct physdev_restore_msi {
+ /* IN */
+ uint8_t bus;
+ uint8_t devfn;
+};
+typedef struct physdev_restore_msi physdev_restore_msi_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_restore_msi_t);
+
+#define PHYSDEVOP_manage_pci_add_ext 20
+struct physdev_manage_pci_ext {
+ /* IN */
+ uint8_t bus;
+ uint8_t devfn;
+ unsigned is_extfn;
+ unsigned is_virtfn;
+ struct {
+ uint8_t bus;
+ uint8_t devfn;
+ } physfn;
+};
+
+typedef struct physdev_manage_pci_ext physdev_manage_pci_ext_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_manage_pci_ext_t);
+
+/*
+ * Argument to physdev_op_compat() hypercall. Superceded by new physdev_op()
+ * hypercall since 0x00030202.
+ */
+struct physdev_op {
+ uint32_t cmd;
+ union {
+ struct physdev_irq_status_query irq_status_query;
+ struct physdev_set_iopl set_iopl;
+ struct physdev_set_iobitmap set_iobitmap;
+ struct physdev_apic apic_op;
+ struct physdev_irq irq_op;
+ } u;
+};
+typedef struct physdev_op physdev_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_op_t);
+
+#define PHYSDEVOP_setup_gsi 21
+struct physdev_setup_gsi {
+ int gsi;
+ /* IN */
+ uint8_t triggering;
+ /* IN */
+ uint8_t polarity;
+ /* IN */
+};
+
+typedef struct physdev_setup_gsi physdev_setup_gsi_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_setup_gsi_t);
+
+/* leave PHYSDEVOP 22 free */
+
+/* type is MAP_PIRQ_TYPE_GSI or MAP_PIRQ_TYPE_MSI
+ * the hypercall returns a free pirq */
+#define PHYSDEVOP_get_free_pirq 23
+struct physdev_get_free_pirq {
+ /* IN */
+ int type;
+ /* OUT */
+ uint32_t pirq;
+};
+
+typedef struct physdev_get_free_pirq physdev_get_free_pirq_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_get_free_pirq_t);
+
+#define XEN_PCI_MMCFG_RESERVED 0x1
+
+#define PHYSDEVOP_pci_mmcfg_reserved 24
+struct physdev_pci_mmcfg_reserved {
+ uint64_t address;
+ uint16_t segment;
+ uint8_t start_bus;
+ uint8_t end_bus;
+ uint32_t flags;
+};
+typedef struct physdev_pci_mmcfg_reserved physdev_pci_mmcfg_reserved_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pci_mmcfg_reserved_t);
+
+#define XEN_PCI_DEV_EXTFN 0x1
+#define XEN_PCI_DEV_VIRTFN 0x2
+#define XEN_PCI_DEV_PXM 0x4
+
+#define PHYSDEVOP_pci_device_add 25
+struct physdev_pci_device_add {
+ /* IN */
+ uint16_t seg;
+ uint8_t bus;
+ uint8_t devfn;
+ uint32_t flags;
+ struct {
+ uint8_t bus;
+ uint8_t devfn;
+ } physfn;
+ /*
+ * Optional parameters array.
+ * First element ([0]) is PXM domain associated with the device (if
+ * XEN_PCI_DEV_PXM is set)
+ */
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
+ uint32_t optarr[];
+#elif defined(__GNUC__)
+ uint32_t optarr[0];
+#endif
+};
+typedef struct physdev_pci_device_add physdev_pci_device_add_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_add_t);
+
+#define PHYSDEVOP_pci_device_remove 26
+#define PHYSDEVOP_restore_msi_ext 27
+/*
+ * Dom0 should use these two to announce MMIO resources assigned to
+ * MSI-X capable devices won't (prepare) or may (release) change.
+ */
+#define PHYSDEVOP_prepare_msix 30
+#define PHYSDEVOP_release_msix 31
+struct physdev_pci_device {
+ /* IN */
+ uint16_t seg;
+ uint8_t bus;
+ uint8_t devfn;
+};
+typedef struct physdev_pci_device physdev_pci_device_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
+
+#define PHYSDEVOP_DBGP_RESET_PREPARE 1
+#define PHYSDEVOP_DBGP_RESET_DONE 2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN 0
+#define PHYSDEVOP_DBGP_BUS_PCI 1
+
+#define PHYSDEVOP_dbgp_op 29
+struct physdev_dbgp_op {
+ /* IN */
+ uint8_t op;
+ uint8_t bus;
+ union {
+ struct physdev_pci_device pci;
+ } u;
+};
+typedef struct physdev_dbgp_op physdev_dbgp_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
+
+/*
+ * Notify that some PIRQ-bound event channels have been unmasked.
+ * ** This command is obsolete since interface version 0x00030202 and is **
+ * ** unsupported by newer versions of Xen. **
+ */
+#define PHYSDEVOP_IRQ_UNMASK_NOTIFY 4
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040600
+/*
+ * These all-capitals physdev operation names are superceded by the new names
+ * (defined above) since interface version 0x00030202. The guard above was
+ * added post-4.5 only though and hence shouldn't check for 0x00030202.
+ */
+#define PHYSDEVOP_IRQ_STATUS_QUERY PHYSDEVOP_irq_status_query
+#define PHYSDEVOP_SET_IOPL PHYSDEVOP_set_iopl
+#define PHYSDEVOP_SET_IOBITMAP PHYSDEVOP_set_iobitmap
+#define PHYSDEVOP_APIC_READ PHYSDEVOP_apic_read
+#define PHYSDEVOP_APIC_WRITE PHYSDEVOP_apic_write
+#define PHYSDEVOP_ASSIGN_VECTOR PHYSDEVOP_alloc_irq_vector
+#define PHYSDEVOP_FREE_VECTOR PHYSDEVOP_free_irq_vector
+#define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi
+#define PHYSDEVOP_IRQ_SHARED XENIRQSTAT_shared
+#endif
+
+#if __XEN_INTERFACE_VERSION__ < 0x00040200
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
+#else
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
+#endif
+
+#endif /* __XEN_PUBLIC_PHYSDEV_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/trace.h b/include/xen/trace.h
new file mode 100644
index 000000000..3746bff26
--- /dev/null
+++ b/include/xen/trace.h
@@ -0,0 +1,339 @@
+/******************************************************************************
+ * include/public/trace.h
+ *
+ * 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.
+ *
+ * Mark Williamson, (C) 2004 Intel Research Cambridge
+ * Copyright (C) 2005 Bin Ren
+ */
+
+#ifndef __XEN_PUBLIC_TRACE_H__
+#define __XEN_PUBLIC_TRACE_H__
+
+#define TRACE_EXTRA_MAX 7
+#define TRACE_EXTRA_SHIFT 28
+
+/* Trace classes */
+#define TRC_CLS_SHIFT 16
+#define TRC_GEN 0x0001f000 /* General trace */
+#define TRC_SCHED 0x0002f000 /* Xen Scheduler trace */
+#define TRC_DOM0OP 0x0004f000 /* Xen DOM0 operation trace */
+#define TRC_HVM 0x0008f000 /* Xen HVM trace */
+#define TRC_MEM 0x0010f000 /* Xen memory trace */
+#define TRC_PV 0x0020f000 /* Xen PV traces */
+#define TRC_SHADOW 0x0040f000 /* Xen shadow tracing */
+#define TRC_HW 0x0080f000 /* Xen hardware-related traces */
+#define TRC_GUEST 0x0800f000 /* Guest-generated traces */
+#define TRC_ALL 0x0ffff000
+#define TRC_HD_TO_EVENT(x) ((x)&0x0fffffff)
+#define TRC_HD_CYCLE_FLAG (1UL<<31)
+#define TRC_HD_INCLUDES_CYCLE_COUNT(x) ( !!( (x) & TRC_HD_CYCLE_FLAG ) )
+#define TRC_HD_EXTRA(x) (((x)>>TRACE_EXTRA_SHIFT)&TRACE_EXTRA_MAX)
+
+/* Trace subclasses */
+#define TRC_SUBCLS_SHIFT 12
+
+/* trace subclasses for SVM */
+#define TRC_HVM_ENTRYEXIT 0x00081000 /* VMENTRY and #VMEXIT */
+#define TRC_HVM_HANDLER 0x00082000 /* various HVM handlers */
+#define TRC_HVM_EMUL 0x00084000 /* emulated devices */
+
+#define TRC_SCHED_MIN 0x00021000 /* Just runstate changes */
+#define TRC_SCHED_CLASS 0x00022000 /* Scheduler-specific */
+#define TRC_SCHED_VERBOSE 0x00028000 /* More inclusive scheduling */
+
+/*
+ * The highest 3 bits of the last 12 bits of TRC_SCHED_CLASS above are
+ * reserved for encoding what scheduler produced the information. The
+ * actual event is encoded in the last 9 bits.
+ *
+ * This means we have 8 scheduling IDs available (which means at most 8
+ * schedulers generating events) and, in each scheduler, up to 512
+ * different events.
+ */
+#define TRC_SCHED_ID_BITS 3
+#define TRC_SCHED_ID_SHIFT (TRC_SUBCLS_SHIFT - TRC_SCHED_ID_BITS)
+#define TRC_SCHED_ID_MASK (((1UL<<TRC_SCHED_ID_BITS) - 1) << TRC_SCHED_ID_SHIFT)
+#define TRC_SCHED_EVT_MASK (~(TRC_SCHED_ID_MASK))
+
+/* Per-scheduler IDs, to identify scheduler specific events */
+#define TRC_SCHED_CSCHED 0
+#define TRC_SCHED_CSCHED2 1
+/* #define XEN_SCHEDULER_SEDF 2 (Removed) */
+#define TRC_SCHED_ARINC653 3
+#define TRC_SCHED_RTDS 4
+#define TRC_SCHED_SNULL 5
+
+/* Per-scheduler tracing */
+#define TRC_SCHED_CLASS_EVT(_c, _e) \
+ ( ( TRC_SCHED_CLASS | \
+ ((TRC_SCHED_##_c << TRC_SCHED_ID_SHIFT) & TRC_SCHED_ID_MASK) ) + \
+ (_e & TRC_SCHED_EVT_MASK) )
+
+/* Trace classes for DOM0 operations */
+#define TRC_DOM0_DOMOPS 0x00041000 /* Domains manipulations */
+
+/* Trace classes for Hardware */
+#define TRC_HW_PM 0x00801000 /* Power management traces */
+#define TRC_HW_IRQ 0x00802000 /* Traces relating to the handling of IRQs */
+
+/* Trace events per class */
+#define TRC_LOST_RECORDS (TRC_GEN + 1)
+#define TRC_TRACE_WRAP_BUFFER (TRC_GEN + 2)
+#define TRC_TRACE_CPU_CHANGE (TRC_GEN + 3)
+
+#define TRC_SCHED_RUNSTATE_CHANGE (TRC_SCHED_MIN + 1)
+#define TRC_SCHED_CONTINUE_RUNNING (TRC_SCHED_MIN + 2)
+#define TRC_SCHED_DOM_ADD (TRC_SCHED_VERBOSE + 1)
+#define TRC_SCHED_DOM_REM (TRC_SCHED_VERBOSE + 2)
+#define TRC_SCHED_SLEEP (TRC_SCHED_VERBOSE + 3)
+#define TRC_SCHED_WAKE (TRC_SCHED_VERBOSE + 4)
+#define TRC_SCHED_YIELD (TRC_SCHED_VERBOSE + 5)
+#define TRC_SCHED_BLOCK (TRC_SCHED_VERBOSE + 6)
+#define TRC_SCHED_SHUTDOWN (TRC_SCHED_VERBOSE + 7)
+#define TRC_SCHED_CTL (TRC_SCHED_VERBOSE + 8)
+#define TRC_SCHED_ADJDOM (TRC_SCHED_VERBOSE + 9)
+#define TRC_SCHED_SWITCH (TRC_SCHED_VERBOSE + 10)
+#define TRC_SCHED_S_TIMER_FN (TRC_SCHED_VERBOSE + 11)
+#define TRC_SCHED_T_TIMER_FN (TRC_SCHED_VERBOSE + 12)
+#define TRC_SCHED_DOM_TIMER_FN (TRC_SCHED_VERBOSE + 13)
+#define TRC_SCHED_SWITCH_INFPREV (TRC_SCHED_VERBOSE + 14)
+#define TRC_SCHED_SWITCH_INFNEXT (TRC_SCHED_VERBOSE + 15)
+#define TRC_SCHED_SHUTDOWN_CODE (TRC_SCHED_VERBOSE + 16)
+#define TRC_SCHED_SWITCH_INFCONT (TRC_SCHED_VERBOSE + 17)
+
+#define TRC_DOM0_DOM_ADD (TRC_DOM0_DOMOPS + 1)
+#define TRC_DOM0_DOM_REM (TRC_DOM0_DOMOPS + 2)
+
+#define TRC_MEM_PAGE_GRANT_MAP (TRC_MEM + 1)
+#define TRC_MEM_PAGE_GRANT_UNMAP (TRC_MEM + 2)
+#define TRC_MEM_PAGE_GRANT_TRANSFER (TRC_MEM + 3)
+#define TRC_MEM_SET_P2M_ENTRY (TRC_MEM + 4)
+#define TRC_MEM_DECREASE_RESERVATION (TRC_MEM + 5)
+#define TRC_MEM_POD_POPULATE (TRC_MEM + 16)
+#define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17)
+#define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18)
+
+#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */
+#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */
+
+#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1)
+#define TRC_PV_TRAP (TRC_PV_ENTRY + 3)
+#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4)
+#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5)
+#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6)
+#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7)
+#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8)
+#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9)
+#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10)
+#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11)
+#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12)
+#define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13)
+#define TRC_PV_HYPERCALL_SUBCALL (TRC_PV_SUBCALL + 14)
+
+/*
+ * TRC_PV_HYPERCALL_V2 format
+ *
+ * Only some of the hypercall argument are recorded. Bit fields A0 to
+ * A5 in the first extra word are set if the argument is present and
+ * the arguments themselves are packed sequentially in the following
+ * words.
+ *
+ * The TRC_64_FLAG bit is not set for these events (even if there are
+ * 64-bit arguments in the record).
+ *
+ * Word
+ * 0 bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0
+ * A5 |A4 |A3 |A2 |A1 |A0 |Hypercall op
+ * 1 First 32 bit (or low word of first 64 bit) arg in record
+ * 2 Second 32 bit (or high word of first 64 bit) arg in record
+ * ...
+ *
+ * A0-A5 bitfield values:
+ *
+ * 00b Argument not present
+ * 01b 32-bit argument present
+ * 10b 64-bit argument present
+ * 11b Reserved
+ */
+#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1 << (20 + 2*(i)))
+#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2 << (20 + 2*(i)))
+#define TRC_PV_HYPERCALL_V2_ARG_MASK (0xfff00000)
+
+#define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1)
+#define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2)
+#define TRC_SHADOW_FAST_MMIO (TRC_SHADOW + 3)
+#define TRC_SHADOW_FALSE_FAST_PATH (TRC_SHADOW + 4)
+#define TRC_SHADOW_MMIO (TRC_SHADOW + 5)
+#define TRC_SHADOW_FIXUP (TRC_SHADOW + 6)
+#define TRC_SHADOW_DOMF_DYING (TRC_SHADOW + 7)
+#define TRC_SHADOW_EMULATE (TRC_SHADOW + 8)
+#define TRC_SHADOW_EMULATE_UNSHADOW_USER (TRC_SHADOW + 9)
+#define TRC_SHADOW_EMULATE_UNSHADOW_EVTINJ (TRC_SHADOW + 10)
+#define TRC_SHADOW_EMULATE_UNSHADOW_UNHANDLED (TRC_SHADOW + 11)
+#define TRC_SHADOW_WRMAP_BF (TRC_SHADOW + 12)
+#define TRC_SHADOW_PREALLOC_UNPIN (TRC_SHADOW + 13)
+#define TRC_SHADOW_RESYNC_FULL (TRC_SHADOW + 14)
+#define TRC_SHADOW_RESYNC_ONLY (TRC_SHADOW + 15)
+
+/* trace events per subclass */
+#define TRC_HVM_NESTEDFLAG (0x400)
+#define TRC_HVM_VMENTRY (TRC_HVM_ENTRYEXIT + 0x01)
+#define TRC_HVM_VMEXIT (TRC_HVM_ENTRYEXIT + 0x02)
+#define TRC_HVM_VMEXIT64 (TRC_HVM_ENTRYEXIT + TRC_64_FLAG + 0x02)
+#define TRC_HVM_PF_XEN (TRC_HVM_HANDLER + 0x01)
+#define TRC_HVM_PF_XEN64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x01)
+#define TRC_HVM_PF_INJECT (TRC_HVM_HANDLER + 0x02)
+#define TRC_HVM_PF_INJECT64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x02)
+#define TRC_HVM_INJ_EXC (TRC_HVM_HANDLER + 0x03)
+#define TRC_HVM_INJ_VIRQ (TRC_HVM_HANDLER + 0x04)
+#define TRC_HVM_REINJ_VIRQ (TRC_HVM_HANDLER + 0x05)
+#define TRC_HVM_IO_READ (TRC_HVM_HANDLER + 0x06)
+#define TRC_HVM_IO_WRITE (TRC_HVM_HANDLER + 0x07)
+#define TRC_HVM_CR_READ (TRC_HVM_HANDLER + 0x08)
+#define TRC_HVM_CR_READ64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x08)
+#define TRC_HVM_CR_WRITE (TRC_HVM_HANDLER + 0x09)
+#define TRC_HVM_CR_WRITE64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x09)
+#define TRC_HVM_DR_READ (TRC_HVM_HANDLER + 0x0A)
+#define TRC_HVM_DR_WRITE (TRC_HVM_HANDLER + 0x0B)
+#define TRC_HVM_MSR_READ (TRC_HVM_HANDLER + 0x0C)
+#define TRC_HVM_MSR_WRITE (TRC_HVM_HANDLER + 0x0D)
+#define TRC_HVM_CPUID (TRC_HVM_HANDLER + 0x0E)
+#define TRC_HVM_INTR (TRC_HVM_HANDLER + 0x0F)
+#define TRC_HVM_NMI (TRC_HVM_HANDLER + 0x10)
+#define TRC_HVM_SMI (TRC_HVM_HANDLER + 0x11)
+#define TRC_HVM_VMMCALL (TRC_HVM_HANDLER + 0x12)
+#define TRC_HVM_HLT (TRC_HVM_HANDLER + 0x13)
+#define TRC_HVM_INVLPG (TRC_HVM_HANDLER + 0x14)
+#define TRC_HVM_INVLPG64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x14)
+#define TRC_HVM_MCE (TRC_HVM_HANDLER + 0x15)
+#define TRC_HVM_IOPORT_READ (TRC_HVM_HANDLER + 0x16)
+#define TRC_HVM_IOMEM_READ (TRC_HVM_HANDLER + 0x17)
+#define TRC_HVM_CLTS (TRC_HVM_HANDLER + 0x18)
+#define TRC_HVM_LMSW (TRC_HVM_HANDLER + 0x19)
+#define TRC_HVM_LMSW64 (TRC_HVM_HANDLER + TRC_64_FLAG + 0x19)
+#define TRC_HVM_RDTSC (TRC_HVM_HANDLER + 0x1a)
+#define TRC_HVM_INTR_WINDOW (TRC_HVM_HANDLER + 0x20)
+#define TRC_HVM_NPF (TRC_HVM_HANDLER + 0x21)
+#define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
+#define TRC_HVM_TRAP (TRC_HVM_HANDLER + 0x23)
+#define TRC_HVM_TRAP_DEBUG (TRC_HVM_HANDLER + 0x24)
+#define TRC_HVM_VLAPIC (TRC_HVM_HANDLER + 0x25)
+
+#define TRC_HVM_IOPORT_WRITE (TRC_HVM_HANDLER + 0x216)
+#define TRC_HVM_IOMEM_WRITE (TRC_HVM_HANDLER + 0x217)
+
+/* Trace events for emulated devices */
+#define TRC_HVM_EMUL_HPET_START_TIMER (TRC_HVM_EMUL + 0x1)
+#define TRC_HVM_EMUL_PIT_START_TIMER (TRC_HVM_EMUL + 0x2)
+#define TRC_HVM_EMUL_RTC_START_TIMER (TRC_HVM_EMUL + 0x3)
+#define TRC_HVM_EMUL_LAPIC_START_TIMER (TRC_HVM_EMUL + 0x4)
+#define TRC_HVM_EMUL_HPET_STOP_TIMER (TRC_HVM_EMUL + 0x5)
+#define TRC_HVM_EMUL_PIT_STOP_TIMER (TRC_HVM_EMUL + 0x6)
+#define TRC_HVM_EMUL_RTC_STOP_TIMER (TRC_HVM_EMUL + 0x7)
+#define TRC_HVM_EMUL_LAPIC_STOP_TIMER (TRC_HVM_EMUL + 0x8)
+#define TRC_HVM_EMUL_PIT_TIMER_CB (TRC_HVM_EMUL + 0x9)
+#define TRC_HVM_EMUL_LAPIC_TIMER_CB (TRC_HVM_EMUL + 0xA)
+#define TRC_HVM_EMUL_PIC_INT_OUTPUT (TRC_HVM_EMUL + 0xB)
+#define TRC_HVM_EMUL_PIC_KICK (TRC_HVM_EMUL + 0xC)
+#define TRC_HVM_EMUL_PIC_INTACK (TRC_HVM_EMUL + 0xD)
+#define TRC_HVM_EMUL_PIC_POSEDGE (TRC_HVM_EMUL + 0xE)
+#define TRC_HVM_EMUL_PIC_NEGEDGE (TRC_HVM_EMUL + 0xF)
+#define TRC_HVM_EMUL_PIC_PEND_IRQ_CALL (TRC_HVM_EMUL + 0x10)
+#define TRC_HVM_EMUL_LAPIC_PIC_INTR (TRC_HVM_EMUL + 0x11)
+
+/* trace events for per class */
+#define TRC_PM_FREQ_CHANGE (TRC_HW_PM + 0x01)
+#define TRC_PM_IDLE_ENTRY (TRC_HW_PM + 0x02)
+#define TRC_PM_IDLE_EXIT (TRC_HW_PM + 0x03)
+
+/* Trace events for IRQs */
+#define TRC_HW_IRQ_MOVE_CLEANUP_DELAY (TRC_HW_IRQ + 0x1)
+#define TRC_HW_IRQ_MOVE_CLEANUP (TRC_HW_IRQ + 0x2)
+#define TRC_HW_IRQ_BIND_VECTOR (TRC_HW_IRQ + 0x3)
+#define TRC_HW_IRQ_CLEAR_VECTOR (TRC_HW_IRQ + 0x4)
+#define TRC_HW_IRQ_MOVE_FINISH (TRC_HW_IRQ + 0x5)
+#define TRC_HW_IRQ_ASSIGN_VECTOR (TRC_HW_IRQ + 0x6)
+#define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7)
+#define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8)
+
+/*
+ * Event Flags
+ *
+ * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple
+ * record formats. These event flags distinguish between the
+ * different formats.
+ */
+#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */
+
+/* This structure represents a single trace buffer record. */
+struct t_rec {
+ uint32_t event:28;
+ uint32_t extra_u32:3; /* # entries in trailing extra_u32[] array */
+ uint32_t cycles_included:1; /* u.cycles or u.no_cycles? */
+ union {
+ struct {
+ uint32_t cycles_lo, cycles_hi; /* cycle counter timestamp */
+ uint32_t extra_u32[7]; /* event data items */
+ } cycles;
+ struct {
+ uint32_t extra_u32[7]; /* event data items */
+ } nocycles;
+ } u;
+};
+
+/*
+ * This structure contains the metadata for a single trace buffer. The head
+ * field, indexes into an array of struct t_rec's.
+ */
+struct t_buf {
+ /* Assume the data buffer size is X. X is generally not a power of 2.
+ * CONS and PROD are incremented modulo (2*X):
+ * 0 <= cons < 2*X
+ * 0 <= prod < 2*X
+ * This is done because addition modulo X breaks at 2^32 when X is not a
+ * power of 2:
+ * (((2^32 - 1) % X) + 1) % X != (2^32) % X
+ */
+ uint32_t cons; /* Offset of next item to be consumed by control tools. */
+ uint32_t prod; /* Offset of next item to be produced by Xen. */
+ /* Records follow immediately after the meta-data header. */
+};
+
+/* Structure used to pass MFNs to the trace buffers back to trace consumers.
+ * Offset is an offset into the mapped structure where the mfn list will be held.
+ * MFNs will be at ((unsigned long *)(t_info))+(t_info->cpu_offset[cpu]).
+ */
+struct t_info {
+ uint16_t tbuf_size; /* Size in pages of each trace buffer */
+ uint16_t mfn_offset[]; /* Offset within t_info structure of the page list per cpu */
+ /* MFN lists immediately after the header */
+};
+
+#endif /* __XEN_PUBLIC_TRACE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 6c9e42b2b..308109f17 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -53,17 +53,22 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t);
DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
-/* Turn a plain number into a C unsigned (long) constant. */
+/* Turn a plain number into a C unsigned (long (long)) constant. */
#define __xen_mk_uint(x) x ## U
#define __xen_mk_ulong(x) x ## UL
+#ifndef __xen_mk_ullong
+# define __xen_mk_ullong(x) x ## ULL
+#endif
#define xen_mk_uint(x) __xen_mk_uint(x)
#define xen_mk_ulong(x) __xen_mk_ulong(x)
+#define xen_mk_ullong(x) __xen_mk_ullong(x)
#else
/* In assembly code we cannot use C numeric constant suffixes. */
-#define xen_mk_uint(x) x
-#define xen_mk_ulong(x) x
+#define xen_mk_uint(x) x
+#define xen_mk_ulong(x) x
+#define xen_mk_ullong(x) x
#endif
@@ -115,6 +120,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
#define __HYPERVISOR_tmem_op 38
#define __HYPERVISOR_xc_reserved_op 39 /* reserved for XenClient */
#define __HYPERVISOR_xenpmu_op 40
+#define __HYPERVISOR_dm_op 41
/* Architecture-specific hypercall definitions. */
#define __HYPERVISOR_arch_0 48
@@ -501,6 +507,21 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
/* x86/PAE guests: support PDPTs above 4GB. */
#define VMASST_TYPE_pae_extended_cr3 3
+/*
+ * x86 guests: Sane behaviour for virtual iopl
+ * - virtual iopl updated from do_iret() hypercalls.
+ * - virtual iopl reported in bounce frames.
+ * - guest kernels assumed to be level 0 for the purpose of iopl checks.
+ */
+#define VMASST_TYPE_architectural_iopl 4
+
+/*
+ * All guests: activate update indicator in vcpu_runstate_info
+ * Enable setting the XEN_RUNSTATE_UPDATE flag in guest memory mapped
+ * vcpu_runstate_info during updates of the runstate information.
+ */
+#define VMASST_TYPE_runstate_update_flag 5
+
/*
* x86/64 guests: strictly hide M2P from user mode.
* This allows the guest to control respective hypervisor behavior:
@@ -529,16 +550,21 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
* is useful to ensure that no mappings to the OS's own heap are accidentally
* installed. (e.g., in Linux this could cause havoc as reference counts
* aren't adjusted on the I/O-mapping code path).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, but in that context can
- * be specified by any calling domain.
+ * This only makes sense as HYPERVISOR_mmu_update()'s and
+ * HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument. For
+ * HYPERVISOR_mmu_update() context it can be specified by any calling domain,
+ * otherwise it's only permitted if the caller is privileged.
*/
#define DOMID_IO xen_mk_uint(0x7FF1)
/*
* DOMID_XEN is used to allow privileged domains to map restricted parts of
* Xen's heap space (e.g., the machine_to_phys table).
- * This only makes sense in MMUEXT_SET_FOREIGNDOM, and is only permitted if
- * the caller is privileged.
+ * This only makes sense as
+ * - HYPERVISOR_mmu_update()'s, HYPERVISOR_mmuext_op()'s, or
+ * HYPERVISOR_update_va_mapping_otherdomain()'s "foreigndom" argument,
+ * - with XENMAPSPACE_gmfn_foreign,
+ * and is only permitted if the caller is privileged.
*/
#define DOMID_XEN xen_mk_uint(0x7FF2)
@@ -614,10 +640,18 @@ struct vcpu_time_info {
*/
uint32_t tsc_to_system_mul;
int8_t tsc_shift;
+#if __XEN_INTERFACE_VERSION__ > 0x040600
+ uint8_t flags;
+ uint8_t pad1[2];
+#else
int8_t pad1[3];
+#endif
}; /* 32 bytes */
typedef struct vcpu_time_info vcpu_time_info_t;
+#define XEN_PVCLOCK_TSC_STABLE_BIT (1 << 0)
+#define XEN_PVCLOCK_GUEST_STOPPED (1 << 1)
+
struct vcpu_info {
/*
* 'evtchn_upcall_pending' is written non-zero by Xen to indicate
@@ -736,7 +770,7 @@ typedef struct shared_info shared_info_t;
* (may be omitted)
* c. list of allocated page frames [mfn_list, nr_pages]
* (unless relocated due to XEN_ELFNOTE_INIT_P2M)
- * d. start_info_t structure [register ESI (x86)]
+ * d. start_info_t structure [register rSI (x86)]
* in case of dom0 this page contains the console info, too
* e. unless dom0: xenstore ring page
* f. unless dom0: console ring page
@@ -797,29 +831,6 @@ struct start_info {
};
typedef struct start_info start_info_t;
-/*
- * Start of day structure passed to PVH 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.
- */
-struct hvm_start_info {
-#define HVM_START_MAGIC_VALUE 0x336ec578
- uint32_t magic; /* Contains the magic value 0x336ec578 */
- /* ("xEn3" with the 0x80 bit of the "E" set).*/
- uint32_t flags; /* SIF_xxx flags. */
- uint32_t cmdline_paddr; /* Physical address of the command line. */
- uint32_t nr_modules; /* Number of modules passed to the kernel. */
- uint32_t modlist_paddr; /* Physical address of an array of */
- /* hvm_modlist_entry. */
-};
-
-struct hvm_modlist_entry {
- uint32_t paddr; /* Physical address of the module. */
- uint32_t size; /* Size of the module in bytes. */
-};
-
/* New console union for dom0 introduced in 0x00030203. */
#if __XEN_INTERFACE_VERSION__ < 0x00030203
#define console_mfn console.domU.mfn
@@ -919,6 +930,37 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
__DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
__DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
+typedef struct {
+ uint8_t a[16];
+} xen_uuid_t;
+
+/*
+ * XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
+ * 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
+ * will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
+ * {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
+ * 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff};
+ *
+ * NB: This is compatible with Linux kernel and with libuuid, but it is not
+ * compatible with Microsoft, as they use mixed-endian encoding (some
+ * components are little-endian, some are big-endian).
+ */
+#define XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6) \
+ {{((a) >> 24) & 0xFF, ((a) >> 16) & 0xFF, \
+ ((a) >> 8) & 0xFF, ((a) >> 0) & 0xFF, \
+ ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \
+ ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, \
+ ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, \
+ e1, e2, e3, e4, e5, e6}}
+
+#if defined(__STDC_VERSION__) ? __STDC_VERSION__ >= 199901L : defined(__GNUC__)
+#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
+ ((xen_uuid_t)XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6))
+#else
+#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
+ XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)
+#endif /* __STDC_VERSION__ / __GNUC__ */
+
#endif /* !__ASSEMBLY__ */
/* Default definitions for macros used by domctl/sysctl. */
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 01/18] xen: add some xen headers
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-18 13:45 ` Daniel Kiper
2018-10-18 14:04 ` Juergen Gross
2018-10-18 14:04 ` Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 13:45 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote:
> In order to support grub2 in Xen PVH environment some additional Xen
> headers are needed as grub2 will be started in PVH mode requiring to
> use several HVM hypercalls and structures.
>
> Add the needed headers from Xen 4.10 being the first Xen version with
> full (not only experimental) PVH guest support.
Should not we use the latest one? 4.11?
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 01/18] xen: add some xen headers
2018-10-18 13:45 ` Daniel Kiper
@ 2018-10-18 14:04 ` Juergen Gross
2018-10-18 14:14 ` Daniel Kiper
2018-10-18 14:14 ` Daniel Kiper
2018-10-18 14:04 ` Juergen Gross
1 sibling, 2 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:04 UTC (permalink / raw)
To: The development of GNU GRUB, Daniel Kiper; +Cc: hans, phcoder, xen-devel
On 18/10/2018 15:45, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote:
>> In order to support grub2 in Xen PVH environment some additional Xen
>> headers are needed as grub2 will be started in PVH mode requiring to
>> use several HVM hypercalls and structures.
>>
>> Add the needed headers from Xen 4.10 being the first Xen version with
>> full (not only experimental) PVH guest support.
>
> Should not we use the latest one? 4.11?
Hmm, that shouldn't really matter here. All used interfaces are
stable, so in case we don't need any later add-ons (which we don't)
using the 4.10 ones must be fine.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 01/18] xen: add some xen headers
2018-10-18 14:04 ` Juergen Gross
@ 2018-10-18 14:14 ` Daniel Kiper
2018-10-18 14:14 ` Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:14 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, The development of GNU GRUB, xen-devel, phcoder
On Thu, Oct 18, 2018 at 04:04:04PM +0200, Juergen Gross wrote:
> On 18/10/2018 15:45, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote:
> >> In order to support grub2 in Xen PVH environment some additional Xen
> >> headers are needed as grub2 will be started in PVH mode requiring to
> >> use several HVM hypercalls and structures.
> >>
> >> Add the needed headers from Xen 4.10 being the first Xen version with
> >> full (not only experimental) PVH guest support.
> >
> > Should not we use the latest one? 4.11?
>
> Hmm, that shouldn't really matter here. All used interfaces are
> stable, so in case we don't need any later add-ons (which we don't)
> using the 4.10 ones must be fine.
OK, Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 01/18] xen: add some xen headers
2018-10-18 14:04 ` Juergen Gross
2018-10-18 14:14 ` Daniel Kiper
@ 2018-10-18 14:14 ` Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:14 UTC (permalink / raw)
To: Juergen Gross; +Cc: The development of GNU GRUB, hans, phcoder, xen-devel
On Thu, Oct 18, 2018 at 04:04:04PM +0200, Juergen Gross wrote:
> On 18/10/2018 15:45, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote:
> >> In order to support grub2 in Xen PVH environment some additional Xen
> >> headers are needed as grub2 will be started in PVH mode requiring to
> >> use several HVM hypercalls and structures.
> >>
> >> Add the needed headers from Xen 4.10 being the first Xen version with
> >> full (not only experimental) PVH guest support.
> >
> > Should not we use the latest one? 4.11?
>
> Hmm, that shouldn't really matter here. All used interfaces are
> stable, so in case we don't need any later add-ons (which we don't)
> using the 4.10 ones must be fine.
OK, Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 01/18] xen: add some xen headers
2018-10-18 13:45 ` Daniel Kiper
2018-10-18 14:04 ` Juergen Gross
@ 2018-10-18 14:04 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:04 UTC (permalink / raw)
To: The development of GNU GRUB, Daniel Kiper; +Cc: hans, phcoder, xen-devel
On 18/10/2018 15:45, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote:
>> In order to support grub2 in Xen PVH environment some additional Xen
>> headers are needed as grub2 will be started in PVH mode requiring to
>> use several HVM hypercalls and structures.
>>
>> Add the needed headers from Xen 4.10 being the first Xen version with
>> full (not only experimental) PVH guest support.
>
> Should not we use the latest one? 4.11?
Hmm, that shouldn't really matter here. All used interfaces are
stable, so in case we don't need any later add-ons (which we don't)
using the 4.10 ones must be fine.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 01/18] xen: add some xen headers
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-18 13:45 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 13:45 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:00PM +0200, Juergen Gross wrote:
> In order to support grub2 in Xen PVH environment some additional Xen
> headers are needed as grub2 will be started in PVH mode requiring to
> use several HVM hypercalls and structures.
>
> Add the needed headers from Xen 4.10 being the first Xen version with
> full (not only experimental) PVH guest support.
Should not we use the latest one? 4.11?
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Xen PVH guests will have the RSDP at an arbitrary address. Support that
by passing the RSDP address via the boot parameters to Linux.
The new protocol version 2.14 requires to set version to 0x8000 ored
with the actually use protocol version (the minimum of the kernel
supplied protocol version and the grub2 supported protocol version)
if 2.14 or higher are in effect.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: add oring 0x8000 to version field
---
grub-core/loader/i386/linux.c | 9 +++++++++
include/grub/i386/linux.h | 5 ++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
index 4eab55a2d..f96309476 100644
--- a/grub-core/loader/i386/linux.c
+++ b/grub-core/loader/i386/linux.c
@@ -35,6 +35,7 @@
#include <grub/i18n.h>
#include <grub/lib/cmdline.h>
#include <grub/linux.h>
+#include <grub/machine/kernel.h>
GRUB_MOD_LICENSE ("GPLv3+");
@@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
prot_init_space = page_align (prot_size) * 3;
}
+#ifdef GRUB_KERNEL_USE_RSDP_ADDR
+ if (grub_le_to_cpu16 (lh.version) >= 0x020e)
+ lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
+#endif
+
+ if (grub_le_to_cpu16 (lh.version) >= 0x020e)
+ lh.version = grub_le_to_cpu16 (LINUX_LOADER_VERSION_TAG | 0x020e);
+
if (allocate_pages (prot_size, &align,
min_align, relocatable,
preferred_address))
diff --git a/include/grub/i386/linux.h b/include/grub/i386/linux.h
index 60c7c3b5e..5cbcfbe5a 100644
--- a/include/grub/i386/linux.h
+++ b/include/grub/i386/linux.h
@@ -87,7 +87,7 @@ enum
GRUB_VIDEO_LINUX_TYPE_SIMPLE = 0x70 /* Linear framebuffer without any additional functions. */
};
-/* For the Linux/i386 boot protocol version 2.10. */
+/* For the Linux/i386 boot protocol version 2.14. */
struct linux_i386_kernel_header
{
grub_uint8_t code1[0x0020];
@@ -105,6 +105,7 @@ struct linux_i386_kernel_header
grub_uint16_t jump; /* Jump instruction */
grub_uint32_t header; /* Magic signature "HdrS" */
grub_uint16_t version; /* Boot protocol version supported */
+#define LINUX_LOADER_VERSION_TAG 0x8000
grub_uint32_t realmode_swtch; /* Boot loader hook */
grub_uint16_t start_sys; /* The load-low segment (obsolete) */
grub_uint16_t kernel_version; /* Points to kernel version string */
@@ -142,6 +143,8 @@ struct linux_i386_kernel_header
grub_uint64_t setup_data;
grub_uint64_t pref_address;
grub_uint32_t init_size;
+ grub_uint32_t handover_offset;
+ grub_uint64_t acpi_rsdp_addr;
} GRUB_PACKED;
/* Boot parameters for Linux based on 2.6.12. This is used by the setup
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Xen PVH guests will have the RSDP at an arbitrary address. Support that
by passing the RSDP address via the boot parameters to Linux.
The new protocol version 2.14 requires to set version to 0x8000 ored
with the actually use protocol version (the minimum of the kernel
supplied protocol version and the grub2 supported protocol version)
if 2.14 or higher are in effect.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: add oring 0x8000 to version field
---
grub-core/loader/i386/linux.c | 9 +++++++++
include/grub/i386/linux.h | 5 ++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
index 4eab55a2d..f96309476 100644
--- a/grub-core/loader/i386/linux.c
+++ b/grub-core/loader/i386/linux.c
@@ -35,6 +35,7 @@
#include <grub/i18n.h>
#include <grub/lib/cmdline.h>
#include <grub/linux.h>
+#include <grub/machine/kernel.h>
GRUB_MOD_LICENSE ("GPLv3+");
@@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
prot_init_space = page_align (prot_size) * 3;
}
+#ifdef GRUB_KERNEL_USE_RSDP_ADDR
+ if (grub_le_to_cpu16 (lh.version) >= 0x020e)
+ lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
+#endif
+
+ if (grub_le_to_cpu16 (lh.version) >= 0x020e)
+ lh.version = grub_le_to_cpu16 (LINUX_LOADER_VERSION_TAG | 0x020e);
+
if (allocate_pages (prot_size, &align,
min_align, relocatable,
preferred_address))
diff --git a/include/grub/i386/linux.h b/include/grub/i386/linux.h
index 60c7c3b5e..5cbcfbe5a 100644
--- a/include/grub/i386/linux.h
+++ b/include/grub/i386/linux.h
@@ -87,7 +87,7 @@ enum
GRUB_VIDEO_LINUX_TYPE_SIMPLE = 0x70 /* Linear framebuffer without any additional functions. */
};
-/* For the Linux/i386 boot protocol version 2.10. */
+/* For the Linux/i386 boot protocol version 2.14. */
struct linux_i386_kernel_header
{
grub_uint8_t code1[0x0020];
@@ -105,6 +105,7 @@ struct linux_i386_kernel_header
grub_uint16_t jump; /* Jump instruction */
grub_uint32_t header; /* Magic signature "HdrS" */
grub_uint16_t version; /* Boot protocol version supported */
+#define LINUX_LOADER_VERSION_TAG 0x8000
grub_uint32_t realmode_swtch; /* Boot loader hook */
grub_uint16_t start_sys; /* The load-low segment (obsolete) */
grub_uint16_t kernel_version; /* Points to kernel version string */
@@ -142,6 +143,8 @@ struct linux_i386_kernel_header
grub_uint64_t setup_data;
grub_uint64_t pref_address;
grub_uint32_t init_size;
+ grub_uint32_t handover_offset;
+ grub_uint64_t acpi_rsdp_addr;
} GRUB_PACKED;
/* Boot parameters for Linux based on 2.6.12. This is used by the setup
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-18 14:13 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:13 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> by passing the RSDP address via the boot parameters to Linux.
>
> The new protocol version 2.14 requires to set version to 0x8000 ored
> with the actually use protocol version (the minimum of the kernel
> supplied protocol version and the grub2 supported protocol version)
> if 2.14 or higher are in effect.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V2: add oring 0x8000 to version field
> ---
> grub-core/loader/i386/linux.c | 9 +++++++++
> include/grub/i386/linux.h | 5 ++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> index 4eab55a2d..f96309476 100644
> --- a/grub-core/loader/i386/linux.c
> +++ b/grub-core/loader/i386/linux.c
> @@ -35,6 +35,7 @@
> #include <grub/i18n.h>
> #include <grub/lib/cmdline.h>
> #include <grub/linux.h>
> +#include <grub/machine/kernel.h>
Probably this change belongs to another patch.
> GRUB_MOD_LICENSE ("GPLv3+");
>
> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
> prot_init_space = page_align (prot_size) * 3;
> }
>
> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
> +#endif
It seems to me that this belongs to patch #8. Does not it?
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-18 14:13 ` Daniel Kiper
2018-10-18 14:18 ` Juergen Gross
2018-10-18 14:18 ` Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:13 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> by passing the RSDP address via the boot parameters to Linux.
>
> The new protocol version 2.14 requires to set version to 0x8000 ored
> with the actually use protocol version (the minimum of the kernel
> supplied protocol version and the grub2 supported protocol version)
> if 2.14 or higher are in effect.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> V2: add oring 0x8000 to version field
> ---
> grub-core/loader/i386/linux.c | 9 +++++++++
> include/grub/i386/linux.h | 5 ++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> index 4eab55a2d..f96309476 100644
> --- a/grub-core/loader/i386/linux.c
> +++ b/grub-core/loader/i386/linux.c
> @@ -35,6 +35,7 @@
> #include <grub/i18n.h>
> #include <grub/lib/cmdline.h>
> #include <grub/linux.h>
> +#include <grub/machine/kernel.h>
Probably this change belongs to another patch.
> GRUB_MOD_LICENSE ("GPLv3+");
>
> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
> prot_init_space = page_align (prot_size) * 3;
> }
>
> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
> +#endif
It seems to me that this belongs to patch #8. Does not it?
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:13 ` Daniel Kiper
@ 2018-10-18 14:18 ` Juergen Gross
2018-10-18 14:18 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:18 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 18/10/2018 16:13, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
>> by passing the RSDP address via the boot parameters to Linux.
>>
>> The new protocol version 2.14 requires to set version to 0x8000 ored
>> with the actually use protocol version (the minimum of the kernel
>> supplied protocol version and the grub2 supported protocol version)
>> if 2.14 or higher are in effect.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V2: add oring 0x8000 to version field
>> ---
>> grub-core/loader/i386/linux.c | 9 +++++++++
>> include/grub/i386/linux.h | 5 ++++-
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
>> index 4eab55a2d..f96309476 100644
>> --- a/grub-core/loader/i386/linux.c
>> +++ b/grub-core/loader/i386/linux.c
>> @@ -35,6 +35,7 @@
>> #include <grub/i18n.h>
>> #include <grub/lib/cmdline.h>
>> #include <grub/linux.h>
>> +#include <grub/machine/kernel.h>
>
> Probably this change belongs to another patch.
I don't think so.
>
>> GRUB_MOD_LICENSE ("GPLv3+");
>>
>> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
>> prot_init_space = page_align (prot_size) * 3;
>> }
>>
>> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
>> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
>> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
>> +#endif
>
> It seems to me that this belongs to patch #8. Does not it?
No, it is a generic new interface.
It will be used by PVH first, but can be used in other environments,
too.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:13 ` Daniel Kiper
2018-10-18 14:18 ` Juergen Gross
@ 2018-10-18 14:18 ` Juergen Gross
2018-10-18 14:30 ` Daniel Kiper
2018-10-18 14:30 ` Daniel Kiper
1 sibling, 2 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:18 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, xen-devel, phcoder, hans
On 18/10/2018 16:13, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
>> by passing the RSDP address via the boot parameters to Linux.
>>
>> The new protocol version 2.14 requires to set version to 0x8000 ored
>> with the actually use protocol version (the minimum of the kernel
>> supplied protocol version and the grub2 supported protocol version)
>> if 2.14 or higher are in effect.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> V2: add oring 0x8000 to version field
>> ---
>> grub-core/loader/i386/linux.c | 9 +++++++++
>> include/grub/i386/linux.h | 5 ++++-
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
>> index 4eab55a2d..f96309476 100644
>> --- a/grub-core/loader/i386/linux.c
>> +++ b/grub-core/loader/i386/linux.c
>> @@ -35,6 +35,7 @@
>> #include <grub/i18n.h>
>> #include <grub/lib/cmdline.h>
>> #include <grub/linux.h>
>> +#include <grub/machine/kernel.h>
>
> Probably this change belongs to another patch.
I don't think so.
>
>> GRUB_MOD_LICENSE ("GPLv3+");
>>
>> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
>> prot_init_space = page_align (prot_size) * 3;
>> }
>>
>> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
>> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
>> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
>> +#endif
>
> It seems to me that this belongs to patch #8. Does not it?
No, it is a generic new interface.
It will be used by PVH first, but can be used in other environments,
too.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:18 ` Juergen Gross
@ 2018-10-18 14:30 ` Daniel Kiper
2018-10-18 14:36 ` Juergen Gross
2018-10-18 14:30 ` Daniel Kiper
1 sibling, 1 reply; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:30 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
> On 18/10/2018 16:13, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> >> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> >> by passing the RSDP address via the boot parameters to Linux.
> >>
> >> The new protocol version 2.14 requires to set version to 0x8000 ored
> >> with the actually use protocol version (the minimum of the kernel
> >> supplied protocol version and the grub2 supported protocol version)
> >> if 2.14 or higher are in effect.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> V2: add oring 0x8000 to version field
> >> ---
> >> grub-core/loader/i386/linux.c | 9 +++++++++
> >> include/grub/i386/linux.h | 5 ++++-
> >> 2 files changed, 13 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> >> index 4eab55a2d..f96309476 100644
> >> --- a/grub-core/loader/i386/linux.c
> >> +++ b/grub-core/loader/i386/linux.c
> >> @@ -35,6 +35,7 @@
> >> #include <grub/i18n.h>
> >> #include <grub/lib/cmdline.h>
> >> #include <grub/linux.h>
> >> +#include <grub/machine/kernel.h>
> >
> > Probably this change belongs to another patch.
>
> I don't think so.
You do not add anything to this header here and out of the blue you
include it in this file. So, why it is needed here?
> >> GRUB_MOD_LICENSE ("GPLv3+");
> >>
> >> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
> >> prot_init_space = page_align (prot_size) * 3;
> >> }
> >>
> >> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
> >> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
> >> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
> >> +#endif
> >
> > It seems to me that this belongs to patch #8. Does not it?
>
> No, it is a generic new interface.
>
> It will be used by PVH first, but can be used in other environments,
> too.
I do not like this much but if you want me to get it you have to put
a blurb in the commit message why this is not enabled here. And when
it will be enabled...
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:30 ` Daniel Kiper
@ 2018-10-18 14:36 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:36 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 18/10/2018 16:30, Daniel Kiper wrote:
> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
>> On 18/10/2018 16:13, Daniel Kiper wrote:
>>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
>>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
>>>> by passing the RSDP address via the boot parameters to Linux.
>>>>
>>>> The new protocol version 2.14 requires to set version to 0x8000 ored
>>>> with the actually use protocol version (the minimum of the kernel
>>>> supplied protocol version and the grub2 supported protocol version)
>>>> if 2.14 or higher are in effect.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> V2: add oring 0x8000 to version field
>>>> ---
>>>> grub-core/loader/i386/linux.c | 9 +++++++++
>>>> include/grub/i386/linux.h | 5 ++++-
>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
>>>> index 4eab55a2d..f96309476 100644
>>>> --- a/grub-core/loader/i386/linux.c
>>>> +++ b/grub-core/loader/i386/linux.c
>>>> @@ -35,6 +35,7 @@
>>>> #include <grub/i18n.h>
>>>> #include <grub/lib/cmdline.h>
>>>> #include <grub/linux.h>
>>>> +#include <grub/machine/kernel.h>
>>>
>>> Probably this change belongs to another patch.
>>
>> I don't think so.
>
> You do not add anything to this header here and out of the blue you
> include it in this file. So, why it is needed here?
Ah, now I see your problem.
machine/kernel.h will be the header which eventually defines
GRUB_KERNEL_USE_RSDP_ADDR.
>
>>>> GRUB_MOD_LICENSE ("GPLv3+");
>>>>
>>>> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
>>>> prot_init_space = page_align (prot_size) * 3;
>>>> }
>>>>
>>>> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
>>>> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
>>>> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
>>>> +#endif
>>>
>>> It seems to me that this belongs to patch #8. Does not it?
>>
>> No, it is a generic new interface.
>>
>> It will be used by PVH first, but can be used in other environments,
>> too.
>
> I do not like this much but if you want me to get it you have to put
> a blurb in the commit message why this is not enabled here. And when
> it will be enabled...
Okay, will do.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
@ 2018-10-18 14:36 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:36 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, xen-devel, phcoder, hans
On 18/10/2018 16:30, Daniel Kiper wrote:
> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
>> On 18/10/2018 16:13, Daniel Kiper wrote:
>>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
>>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
>>>> by passing the RSDP address via the boot parameters to Linux.
>>>>
>>>> The new protocol version 2.14 requires to set version to 0x8000 ored
>>>> with the actually use protocol version (the minimum of the kernel
>>>> supplied protocol version and the grub2 supported protocol version)
>>>> if 2.14 or higher are in effect.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> V2: add oring 0x8000 to version field
>>>> ---
>>>> grub-core/loader/i386/linux.c | 9 +++++++++
>>>> include/grub/i386/linux.h | 5 ++++-
>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
>>>> index 4eab55a2d..f96309476 100644
>>>> --- a/grub-core/loader/i386/linux.c
>>>> +++ b/grub-core/loader/i386/linux.c
>>>> @@ -35,6 +35,7 @@
>>>> #include <grub/i18n.h>
>>>> #include <grub/lib/cmdline.h>
>>>> #include <grub/linux.h>
>>>> +#include <grub/machine/kernel.h>
>>>
>>> Probably this change belongs to another patch.
>>
>> I don't think so.
>
> You do not add anything to this header here and out of the blue you
> include it in this file. So, why it is needed here?
Ah, now I see your problem.
machine/kernel.h will be the header which eventually defines
GRUB_KERNEL_USE_RSDP_ADDR.
>
>>>> GRUB_MOD_LICENSE ("GPLv3+");
>>>>
>>>> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
>>>> prot_init_space = page_align (prot_size) * 3;
>>>> }
>>>>
>>>> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
>>>> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
>>>> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
>>>> +#endif
>>>
>>> It seems to me that this belongs to patch #8. Does not it?
>>
>> No, it is a generic new interface.
>>
>> It will be used by PVH first, but can be used in other environments,
>> too.
>
> I do not like this much but if you want me to get it you have to put
> a blurb in the commit message why this is not enabled here. And when
> it will be enabled...
Okay, will do.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:36 ` Juergen Gross
@ 2018-10-18 14:48 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:48 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote:
> On 18/10/2018 16:30, Daniel Kiper wrote:
> > On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
> >> On 18/10/2018 16:13, Daniel Kiper wrote:
> >>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> >>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> >>>> by passing the RSDP address via the boot parameters to Linux.
> >>>>
> >>>> The new protocol version 2.14 requires to set version to 0x8000 ored
> >>>> with the actually use protocol version (the minimum of the kernel
> >>>> supplied protocol version and the grub2 supported protocol version)
> >>>> if 2.14 or higher are in effect.
> >>>>
> >>>> Signed-off-by: Juergen Gross <jgross@suse.com>
> >>>> ---
> >>>> V2: add oring 0x8000 to version field
> >>>> ---
> >>>> grub-core/loader/i386/linux.c | 9 +++++++++
> >>>> include/grub/i386/linux.h | 5 ++++-
> >>>> 2 files changed, 13 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> >>>> index 4eab55a2d..f96309476 100644
> >>>> --- a/grub-core/loader/i386/linux.c
> >>>> +++ b/grub-core/loader/i386/linux.c
> >>>> @@ -35,6 +35,7 @@
> >>>> #include <grub/i18n.h>
> >>>> #include <grub/lib/cmdline.h>
> >>>> #include <grub/linux.h>
> >>>> +#include <grub/machine/kernel.h>
> >>>
> >>> Probably this change belongs to another patch.
> >>
> >> I don't think so.
> >
> > You do not add anything to this header here and out of the blue you
> > include it in this file. So, why it is needed here?
>
> Ah, now I see your problem.
>
> machine/kernel.h will be the header which eventually defines
> GRUB_KERNEL_USE_RSDP_ADDR.
So, please move this to the proper patch.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
@ 2018-10-18 14:48 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:48 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote:
> On 18/10/2018 16:30, Daniel Kiper wrote:
> > On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
> >> On 18/10/2018 16:13, Daniel Kiper wrote:
> >>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> >>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> >>>> by passing the RSDP address via the boot parameters to Linux.
> >>>>
> >>>> The new protocol version 2.14 requires to set version to 0x8000 ored
> >>>> with the actually use protocol version (the minimum of the kernel
> >>>> supplied protocol version and the grub2 supported protocol version)
> >>>> if 2.14 or higher are in effect.
> >>>>
> >>>> Signed-off-by: Juergen Gross <jgross@suse.com>
> >>>> ---
> >>>> V2: add oring 0x8000 to version field
> >>>> ---
> >>>> grub-core/loader/i386/linux.c | 9 +++++++++
> >>>> include/grub/i386/linux.h | 5 ++++-
> >>>> 2 files changed, 13 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> >>>> index 4eab55a2d..f96309476 100644
> >>>> --- a/grub-core/loader/i386/linux.c
> >>>> +++ b/grub-core/loader/i386/linux.c
> >>>> @@ -35,6 +35,7 @@
> >>>> #include <grub/i18n.h>
> >>>> #include <grub/lib/cmdline.h>
> >>>> #include <grub/linux.h>
> >>>> +#include <grub/machine/kernel.h>
> >>>
> >>> Probably this change belongs to another patch.
> >>
> >> I don't think so.
> >
> > You do not add anything to this header here and out of the blue you
> > include it in this file. So, why it is needed here?
>
> Ah, now I see your problem.
>
> machine/kernel.h will be the header which eventually defines
> GRUB_KERNEL_USE_RSDP_ADDR.
So, please move this to the proper patch.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:48 ` Daniel Kiper
@ 2018-10-18 14:53 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:53 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 18/10/2018 16:48, Daniel Kiper wrote:
> On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote:
>> On 18/10/2018 16:30, Daniel Kiper wrote:
>>> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
>>>> On 18/10/2018 16:13, Daniel Kiper wrote:
>>>>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
>>>>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
>>>>>> by passing the RSDP address via the boot parameters to Linux.
>>>>>>
>>>>>> The new protocol version 2.14 requires to set version to 0x8000 ored
>>>>>> with the actually use protocol version (the minimum of the kernel
>>>>>> supplied protocol version and the grub2 supported protocol version)
>>>>>> if 2.14 or higher are in effect.
>>>>>>
>>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>>>> ---
>>>>>> V2: add oring 0x8000 to version field
>>>>>> ---
>>>>>> grub-core/loader/i386/linux.c | 9 +++++++++
>>>>>> include/grub/i386/linux.h | 5 ++++-
>>>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
>>>>>> index 4eab55a2d..f96309476 100644
>>>>>> --- a/grub-core/loader/i386/linux.c
>>>>>> +++ b/grub-core/loader/i386/linux.c
>>>>>> @@ -35,6 +35,7 @@
>>>>>> #include <grub/i18n.h>
>>>>>> #include <grub/lib/cmdline.h>
>>>>>> #include <grub/linux.h>
>>>>>> +#include <grub/machine/kernel.h>
>>>>>
>>>>> Probably this change belongs to another patch.
>>>>
>>>> I don't think so.
>>>
>>> You do not add anything to this header here and out of the blue you
>>> include it in this file. So, why it is needed here?
>>
>> Ah, now I see your problem.
>>
>> machine/kernel.h will be the header which eventually defines
>> GRUB_KERNEL_USE_RSDP_ADDR.
>
> So, please move this to the proper patch.
Okay, if you like that better.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
@ 2018-10-18 14:53 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 14:53 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, xen-devel, phcoder, hans
On 18/10/2018 16:48, Daniel Kiper wrote:
> On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote:
>> On 18/10/2018 16:30, Daniel Kiper wrote:
>>> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
>>>> On 18/10/2018 16:13, Daniel Kiper wrote:
>>>>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
>>>>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
>>>>>> by passing the RSDP address via the boot parameters to Linux.
>>>>>>
>>>>>> The new protocol version 2.14 requires to set version to 0x8000 ored
>>>>>> with the actually use protocol version (the minimum of the kernel
>>>>>> supplied protocol version and the grub2 supported protocol version)
>>>>>> if 2.14 or higher are in effect.
>>>>>>
>>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>>>> ---
>>>>>> V2: add oring 0x8000 to version field
>>>>>> ---
>>>>>> grub-core/loader/i386/linux.c | 9 +++++++++
>>>>>> include/grub/i386/linux.h | 5 ++++-
>>>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
>>>>>> index 4eab55a2d..f96309476 100644
>>>>>> --- a/grub-core/loader/i386/linux.c
>>>>>> +++ b/grub-core/loader/i386/linux.c
>>>>>> @@ -35,6 +35,7 @@
>>>>>> #include <grub/i18n.h>
>>>>>> #include <grub/lib/cmdline.h>
>>>>>> #include <grub/linux.h>
>>>>>> +#include <grub/machine/kernel.h>
>>>>>
>>>>> Probably this change belongs to another patch.
>>>>
>>>> I don't think so.
>>>
>>> You do not add anything to this header here and out of the blue you
>>> include it in this file. So, why it is needed here?
>>
>> Ah, now I see your problem.
>>
>> machine/kernel.h will be the header which eventually defines
>> GRUB_KERNEL_USE_RSDP_ADDR.
>
> So, please move this to the proper patch.
Okay, if you like that better.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:53 ` Juergen Gross
@ 2018-10-18 15:01 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 15:01 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Thu, Oct 18, 2018 at 04:53:01PM +0200, Juergen Gross wrote:
> On 18/10/2018 16:48, Daniel Kiper wrote:
> > On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote:
> >> On 18/10/2018 16:30, Daniel Kiper wrote:
> >>> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
> >>>> On 18/10/2018 16:13, Daniel Kiper wrote:
> >>>>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> >>>>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> >>>>>> by passing the RSDP address via the boot parameters to Linux.
> >>>>>>
> >>>>>> The new protocol version 2.14 requires to set version to 0x8000 ored
> >>>>>> with the actually use protocol version (the minimum of the kernel
> >>>>>> supplied protocol version and the grub2 supported protocol version)
> >>>>>> if 2.14 or higher are in effect.
> >>>>>>
> >>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
> >>>>>> ---
> >>>>>> V2: add oring 0x8000 to version field
> >>>>>> ---
> >>>>>> grub-core/loader/i386/linux.c | 9 +++++++++
> >>>>>> include/grub/i386/linux.h | 5 ++++-
> >>>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> >>>>>> index 4eab55a2d..f96309476 100644
> >>>>>> --- a/grub-core/loader/i386/linux.c
> >>>>>> +++ b/grub-core/loader/i386/linux.c
> >>>>>> @@ -35,6 +35,7 @@
> >>>>>> #include <grub/i18n.h>
> >>>>>> #include <grub/lib/cmdline.h>
> >>>>>> #include <grub/linux.h>
> >>>>>> +#include <grub/machine/kernel.h>
> >>>>>
> >>>>> Probably this change belongs to another patch.
> >>>>
> >>>> I don't think so.
> >>>
> >>> You do not add anything to this header here and out of the blue you
> >>> include it in this file. So, why it is needed here?
> >>
> >> Ah, now I see your problem.
> >>
> >> machine/kernel.h will be the header which eventually defines
> >> GRUB_KERNEL_USE_RSDP_ADDR.
> >
> > So, please move this to the proper patch.
>
> Okay, if you like that better.
Yes, I will. Thanks!
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
@ 2018-10-18 15:01 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 15:01 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Thu, Oct 18, 2018 at 04:53:01PM +0200, Juergen Gross wrote:
> On 18/10/2018 16:48, Daniel Kiper wrote:
> > On Thu, Oct 18, 2018 at 04:36:28PM +0200, Juergen Gross wrote:
> >> On 18/10/2018 16:30, Daniel Kiper wrote:
> >>> On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
> >>>> On 18/10/2018 16:13, Daniel Kiper wrote:
> >>>>> On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> >>>>>> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> >>>>>> by passing the RSDP address via the boot parameters to Linux.
> >>>>>>
> >>>>>> The new protocol version 2.14 requires to set version to 0x8000 ored
> >>>>>> with the actually use protocol version (the minimum of the kernel
> >>>>>> supplied protocol version and the grub2 supported protocol version)
> >>>>>> if 2.14 or higher are in effect.
> >>>>>>
> >>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
> >>>>>> ---
> >>>>>> V2: add oring 0x8000 to version field
> >>>>>> ---
> >>>>>> grub-core/loader/i386/linux.c | 9 +++++++++
> >>>>>> include/grub/i386/linux.h | 5 ++++-
> >>>>>> 2 files changed, 13 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> >>>>>> index 4eab55a2d..f96309476 100644
> >>>>>> --- a/grub-core/loader/i386/linux.c
> >>>>>> +++ b/grub-core/loader/i386/linux.c
> >>>>>> @@ -35,6 +35,7 @@
> >>>>>> #include <grub/i18n.h>
> >>>>>> #include <grub/lib/cmdline.h>
> >>>>>> #include <grub/linux.h>
> >>>>>> +#include <grub/machine/kernel.h>
> >>>>>
> >>>>> Probably this change belongs to another patch.
> >>>>
> >>>> I don't think so.
> >>>
> >>> You do not add anything to this header here and out of the blue you
> >>> include it in this file. So, why it is needed here?
> >>
> >> Ah, now I see your problem.
> >>
> >> machine/kernel.h will be the header which eventually defines
> >> GRUB_KERNEL_USE_RSDP_ADDR.
> >
> > So, please move this to the proper patch.
>
> Okay, if you like that better.
Yes, I will. Thanks!
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 02/18] loader/linux: support passing rsdp address via boot params
2018-10-18 14:18 ` Juergen Gross
2018-10-18 14:30 ` Daniel Kiper
@ 2018-10-18 14:30 ` Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:30 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Thu, Oct 18, 2018 at 04:18:26PM +0200, Juergen Gross wrote:
> On 18/10/2018 16:13, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:01PM +0200, Juergen Gross wrote:
> >> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> >> by passing the RSDP address via the boot parameters to Linux.
> >>
> >> The new protocol version 2.14 requires to set version to 0x8000 ored
> >> with the actually use protocol version (the minimum of the kernel
> >> supplied protocol version and the grub2 supported protocol version)
> >> if 2.14 or higher are in effect.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> V2: add oring 0x8000 to version field
> >> ---
> >> grub-core/loader/i386/linux.c | 9 +++++++++
> >> include/grub/i386/linux.h | 5 ++++-
> >> 2 files changed, 13 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
> >> index 4eab55a2d..f96309476 100644
> >> --- a/grub-core/loader/i386/linux.c
> >> +++ b/grub-core/loader/i386/linux.c
> >> @@ -35,6 +35,7 @@
> >> #include <grub/i18n.h>
> >> #include <grub/lib/cmdline.h>
> >> #include <grub/linux.h>
> >> +#include <grub/machine/kernel.h>
> >
> > Probably this change belongs to another patch.
>
> I don't think so.
You do not add anything to this header here and out of the blue you
include it in this file. So, why it is needed here?
> >> GRUB_MOD_LICENSE ("GPLv3+");
> >>
> >> @@ -750,6 +751,14 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
> >> prot_init_space = page_align (prot_size) * 3;
> >> }
> >>
> >> +#ifdef GRUB_KERNEL_USE_RSDP_ADDR
> >> + if (grub_le_to_cpu16 (lh.version) >= 0x020e)
> >> + lh.acpi_rsdp_addr = grub_le_to_cpu64 (grub_rsdp_addr);
> >> +#endif
> >
> > It seems to me that this belongs to patch #8. Does not it?
>
> No, it is a generic new interface.
>
> It will be used by PVH first, but can be used in other environments,
> too.
I do not like this much but if you want me to get it you have to put
a blurb in the commit message why this is not enabled here. And when
it will be enabled...
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 03/18] xen: carve out grant tab initialization into dedicated function
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Initialize the grant tab in a dedicated function. This will enable
using it for PVH guests, too.
Call the new function from grub_machine_init() as this will later
be common between Xen PV and Xen PVH mode.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: update commit message (Daniel Kiper)
---
grub-core/kern/xen/init.c | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 0559c033c..29f5bc23d 100644
--- a/grub-core/kern/xen/init.c
+++ b/grub-core/kern/xen/init.c
@@ -318,6 +318,25 @@ grub_xenstore_dir (const char *dir,
unsigned long gntframe = 0;
+static void
+grub_xen_setup_gnttab (void)
+{
+ struct gnttab_set_version gnttab_setver;
+ struct gnttab_setup_table gnttab_setup;
+
+ grub_memset (&gnttab_setver, 0, sizeof (gnttab_setver));
+
+ gnttab_setver.version = 1;
+ grub_xen_grant_table_op (GNTTABOP_set_version, &gnttab_setver, 1);
+
+ grub_memset (&gnttab_setup, 0, sizeof (gnttab_setup));
+ gnttab_setup.dom = DOMID_SELF;
+ gnttab_setup.nr_frames = 1;
+ gnttab_setup.frame_list.p = &gntframe;
+
+ grub_xen_grant_table_op (GNTTABOP_setup_table, &gnttab_setup, 1);
+}
+
#define MAX_N_UNUSABLE_PAGES 4
static int
@@ -357,26 +376,12 @@ map_all_pages (void)
(grub_xen_mfn_t *) grub_xen_start_page_addr->mfn_list;
grub_uint64_t *pg = (grub_uint64_t *) window;
grub_uint64_t oldpgstart, oldpgend;
- struct gnttab_setup_table gnttab_setup;
- struct gnttab_set_version gnttab_setver;
grub_size_t n_unusable_pages = 0;
struct mmu_update m2p_updates[2 * MAX_N_UNUSABLE_PAGES];
if (total_pages > MAX_TOTAL_PAGES - 4)
total_pages = MAX_TOTAL_PAGES - 4;
- grub_memset (&gnttab_setver, 0, sizeof (gnttab_setver));
-
- gnttab_setver.version = 1;
- grub_xen_grant_table_op (GNTTABOP_set_version, &gnttab_setver, 1);
-
- grub_memset (&gnttab_setup, 0, sizeof (gnttab_setup));
- gnttab_setup.dom = DOMID_SELF;
- gnttab_setup.nr_frames = 1;
- gnttab_setup.frame_list.p = &gntframe;
-
- grub_xen_grant_table_op (GNTTABOP_setup_table, &gnttab_setup, 1);
-
for (j = 0; j < total_pages - n_unusable_pages; j++)
while (!grub_xen_is_page_usable (mfn_list[j]))
{
@@ -537,6 +542,8 @@ grub_machine_init (void)
+ GRUB_KERNEL_MACHINE_MOD_GAP,
GRUB_KERNEL_MACHINE_MOD_ALIGN);
+ grub_xen_setup_gnttab ();
+
map_all_pages ();
grub_console_init ();
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 03/18] xen: carve out grant tab initialization into dedicated function
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Initialize the grant tab in a dedicated function. This will enable
using it for PVH guests, too.
Call the new function from grub_machine_init() as this will later
be common between Xen PV and Xen PVH mode.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: update commit message (Daniel Kiper)
---
grub-core/kern/xen/init.c | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 0559c033c..29f5bc23d 100644
--- a/grub-core/kern/xen/init.c
+++ b/grub-core/kern/xen/init.c
@@ -318,6 +318,25 @@ grub_xenstore_dir (const char *dir,
unsigned long gntframe = 0;
+static void
+grub_xen_setup_gnttab (void)
+{
+ struct gnttab_set_version gnttab_setver;
+ struct gnttab_setup_table gnttab_setup;
+
+ grub_memset (&gnttab_setver, 0, sizeof (gnttab_setver));
+
+ gnttab_setver.version = 1;
+ grub_xen_grant_table_op (GNTTABOP_set_version, &gnttab_setver, 1);
+
+ grub_memset (&gnttab_setup, 0, sizeof (gnttab_setup));
+ gnttab_setup.dom = DOMID_SELF;
+ gnttab_setup.nr_frames = 1;
+ gnttab_setup.frame_list.p = &gntframe;
+
+ grub_xen_grant_table_op (GNTTABOP_setup_table, &gnttab_setup, 1);
+}
+
#define MAX_N_UNUSABLE_PAGES 4
static int
@@ -357,26 +376,12 @@ map_all_pages (void)
(grub_xen_mfn_t *) grub_xen_start_page_addr->mfn_list;
grub_uint64_t *pg = (grub_uint64_t *) window;
grub_uint64_t oldpgstart, oldpgend;
- struct gnttab_setup_table gnttab_setup;
- struct gnttab_set_version gnttab_setver;
grub_size_t n_unusable_pages = 0;
struct mmu_update m2p_updates[2 * MAX_N_UNUSABLE_PAGES];
if (total_pages > MAX_TOTAL_PAGES - 4)
total_pages = MAX_TOTAL_PAGES - 4;
- grub_memset (&gnttab_setver, 0, sizeof (gnttab_setver));
-
- gnttab_setver.version = 1;
- grub_xen_grant_table_op (GNTTABOP_set_version, &gnttab_setver, 1);
-
- grub_memset (&gnttab_setup, 0, sizeof (gnttab_setup));
- gnttab_setup.dom = DOMID_SELF;
- gnttab_setup.nr_frames = 1;
- gnttab_setup.frame_list.p = &gntframe;
-
- grub_xen_grant_table_op (GNTTABOP_setup_table, &gnttab_setup, 1);
-
for (j = 0; j < total_pages - n_unusable_pages; j++)
while (!grub_xen_is_page_usable (mfn_list[j]))
{
@@ -537,6 +542,8 @@ grub_machine_init (void)
+ GRUB_KERNEL_MACHINE_MOD_GAP,
GRUB_KERNEL_MACHINE_MOD_ALIGN);
+ grub_xen_setup_gnttab ();
+
map_all_pages ();
grub_console_init ();
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 03/18] xen: carve out grant tab initialization into dedicated function
2018-10-09 11:03 ` Juergen Gross
@ 2018-10-18 14:35 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:35 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:02PM +0200, Juergen Gross wrote:
> Initialize the grant tab in a dedicated function. This will enable
> using it for PVH guests, too.
>
> Call the new function from grub_machine_init() as this will later
> be common between Xen PV and Xen PVH mode.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 03/18] xen: carve out grant tab initialization into dedicated function
@ 2018-10-18 14:35 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:35 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:02PM +0200, Juergen Gross wrote:
> Initialize the grant tab in a dedicated function. This will enable
> using it for PVH guests, too.
>
> Call the new function from grub_machine_init() as this will later
> be common between Xen PV and Xen PVH mode.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 04/18] xen: prepare common code for Xen PVH support
2018-10-09 11:02 ` Juergen Gross
` (3 preceding siblings ...)
(?)
@ 2018-10-09 11:03 ` Juergen Gross
2018-10-18 14:59 ` Daniel Kiper
-1 siblings, 1 reply; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Some common code needs to be special cased for Xen PVH mode. This hits
mostly Xen PV mode specific areas.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/tsc.c | 2 +-
include/grub/i386/pc/int.h | 3 +++
include/grub/i386/tsc.h | 2 +-
include/grub/i386/xen/hypercall.h | 5 ++++-
include/grub/kernel.h | 4 +++-
5 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
index f266eb131..43fee3a13 100644
--- a/grub-core/kern/i386/tsc.c
+++ b/grub-core/kern/i386/tsc.c
@@ -65,7 +65,7 @@ grub_tsc_init (void)
tsc_boot_time = grub_get_tsc ();
-#ifdef GRUB_MACHINE_XEN
+#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
(void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
#elif defined (GRUB_MACHINE_EFI)
(void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
index 16a53e4fe..46fb1e397 100644
--- a/include/grub/i386/pc/int.h
+++ b/include/grub/i386/pc/int.h
@@ -51,9 +51,12 @@ struct grub_bios_int_registers
#define GRUB_CPU_INT_FLAGS_DEFAULT 0
#endif
+#ifndef GRUB_MACHINE_XENPVH
void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
struct grub_bios_int_registers *regs)
__attribute__ ((regparm(3)));
+#endif
+
struct grub_i386_idt
{
grub_uint16_t limit;
diff --git a/include/grub/i386/tsc.h b/include/grub/i386/tsc.h
index a0aa2c573..8fe1dafa4 100644
--- a/include/grub/i386/tsc.h
+++ b/include/grub/i386/tsc.h
@@ -54,7 +54,7 @@ grub_get_tsc (void)
static __inline int
grub_cpu_is_tsc_supported (void)
{
-#ifndef GRUB_MACHINE_XEN
+#if !defined(GRUB_MACHINE_XEN) && !defined(GRUB_MACHINE_XENPVH)
grub_uint32_t a,b,c,d;
if (! grub_cpu_is_cpuid_supported ())
return 0;
diff --git a/include/grub/i386/xen/hypercall.h b/include/grub/i386/xen/hypercall.h
index 198ee94af..4e4c12a49 100644
--- a/include/grub/i386/xen/hypercall.h
+++ b/include/grub/i386/xen/hypercall.h
@@ -26,7 +26,10 @@ EXPORT_FUNC (grub_xen_hypercall) (grub_uint32_t callno, grub_uint32_t a0,
grub_uint32_t a1, grub_uint32_t a2,
grub_uint32_t a3, grub_uint32_t a4,
grub_uint32_t a5)
-__attribute__ ((regparm (3), cdecl));
+#ifdef GRUB_MACHINE_XEN
+ __attribute__ ((regparm (3), cdecl))
+#endif
+ ;
static inline int
grub_xen_sched_op (int cmd, void *arg)
diff --git a/include/grub/kernel.h b/include/grub/kernel.h
index ecd88ca72..b0f1e923c 100644
--- a/include/grub/kernel.h
+++ b/include/grub/kernel.h
@@ -79,7 +79,9 @@ struct grub_module_info64
#if defined (GRUB_MACHINE_PCBIOS) || defined (GRUB_MACHINE_COREBOOT) \
|| defined (GRUB_MACHINE_MULTIBOOT) || defined (GRUB_MACHINE_MIPS_QEMU_MIPS) \
|| defined (GRUB_MACHINE_MIPS_LOONGSON) || defined (GRUB_MACHINE_ARC) \
- || (defined (__sparc__) && defined (GRUB_MACHINE_IEEE1275)) || defined (GRUB_MACHINE_UBOOT) || defined (GRUB_MACHINE_XEN)
+ || (defined (__sparc__) && defined (GRUB_MACHINE_IEEE1275)) \
+ || defined (GRUB_MACHINE_UBOOT) || defined (GRUB_MACHINE_XEN) \
+ || defined(GRUB_MACHINE_XENPVH)
/* FIXME: stack is between 2 heap regions. Move it. */
#define GRUB_KERNEL_PRELOAD_SPACE_REUSABLE 1
#endif
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 04/18] xen: prepare common code for Xen PVH support
2018-10-09 11:03 ` [PATCH v2 04/18] xen: prepare common code for Xen PVH support Juergen Gross
@ 2018-10-18 14:59 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:59 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote:
> Some common code needs to be special cased for Xen PVH mode. This hits
> mostly Xen PV mode specific areas.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/tsc.c | 2 +-
> include/grub/i386/pc/int.h | 3 +++
> include/grub/i386/tsc.h | 2 +-
> include/grub/i386/xen/hypercall.h | 5 ++++-
> include/grub/kernel.h | 4 +++-
> 5 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
> index f266eb131..43fee3a13 100644
> --- a/grub-core/kern/i386/tsc.c
> +++ b/grub-core/kern/i386/tsc.c
> @@ -65,7 +65,7 @@ grub_tsc_init (void)
>
> tsc_boot_time = grub_get_tsc ();
>
> -#ifdef GRUB_MACHINE_XEN
> +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/
> (void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
> #elif defined (GRUB_MACHINE_EFI)
> (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
> diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
> index 16a53e4fe..46fb1e397 100644
> --- a/include/grub/i386/pc/int.h
> +++ b/include/grub/i386/pc/int.h
> @@ -51,9 +51,12 @@ struct grub_bios_int_registers
> #define GRUB_CPU_INT_FLAGS_DEFAULT 0
> #endif
>
> +#ifndef GRUB_MACHINE_XENPVH
> void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
> struct grub_bios_int_registers *regs)
> __attribute__ ((regparm(3)));
> +#endif
Is it an issue with this declaration? I think that you should take care
about grub-core/kern/i386/int.S. So, relevant Makefile should be
updated instead of this declaration.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 04/18] xen: prepare common code for Xen PVH support
@ 2018-10-18 14:59 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 14:59 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote:
> Some common code needs to be special cased for Xen PVH mode. This hits
> mostly Xen PV mode specific areas.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/tsc.c | 2 +-
> include/grub/i386/pc/int.h | 3 +++
> include/grub/i386/tsc.h | 2 +-
> include/grub/i386/xen/hypercall.h | 5 ++++-
> include/grub/kernel.h | 4 +++-
> 5 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
> index f266eb131..43fee3a13 100644
> --- a/grub-core/kern/i386/tsc.c
> +++ b/grub-core/kern/i386/tsc.c
> @@ -65,7 +65,7 @@ grub_tsc_init (void)
>
> tsc_boot_time = grub_get_tsc ();
>
> -#ifdef GRUB_MACHINE_XEN
> +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/
> (void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
> #elif defined (GRUB_MACHINE_EFI)
> (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
> diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
> index 16a53e4fe..46fb1e397 100644
> --- a/include/grub/i386/pc/int.h
> +++ b/include/grub/i386/pc/int.h
> @@ -51,9 +51,12 @@ struct grub_bios_int_registers
> #define GRUB_CPU_INT_FLAGS_DEFAULT 0
> #endif
>
> +#ifndef GRUB_MACHINE_XENPVH
> void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
> struct grub_bios_int_registers *regs)
> __attribute__ ((regparm(3)));
> +#endif
Is it an issue with this declaration? I think that you should take care
about grub-core/kern/i386/int.S. So, relevant Makefile should be
updated instead of this declaration.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 04/18] xen: prepare common code for Xen PVH support
2018-10-18 14:59 ` Daniel Kiper
(?)
@ 2018-10-18 15:39 ` Juergen Gross
2018-10-19 6:36 ` Juergen Gross
2018-10-19 6:36 ` [Xen-devel] " Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 15:39 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, xen-devel, phcoder, hans
On 18/10/2018 16:59, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote:
>> Some common code needs to be special cased for Xen PVH mode. This hits
>> mostly Xen PV mode specific areas.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/tsc.c | 2 +-
>> include/grub/i386/pc/int.h | 3 +++
>> include/grub/i386/tsc.h | 2 +-
>> include/grub/i386/xen/hypercall.h | 5 ++++-
>> include/grub/kernel.h | 4 +++-
>> 5 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
>> index f266eb131..43fee3a13 100644
>> --- a/grub-core/kern/i386/tsc.c
>> +++ b/grub-core/kern/i386/tsc.c
>> @@ -65,7 +65,7 @@ grub_tsc_init (void)
>>
>> tsc_boot_time = grub_get_tsc ();
>>
>> -#ifdef GRUB_MACHINE_XEN
>> +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
>
> s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/
Okay.
>
>> (void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
>> #elif defined (GRUB_MACHINE_EFI)
>> (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
>> diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
>> index 16a53e4fe..46fb1e397 100644
>> --- a/include/grub/i386/pc/int.h
>> +++ b/include/grub/i386/pc/int.h
>> @@ -51,9 +51,12 @@ struct grub_bios_int_registers
>> #define GRUB_CPU_INT_FLAGS_DEFAULT 0
>> #endif
>>
>> +#ifndef GRUB_MACHINE_XENPVH
>> void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
>> struct grub_bios_int_registers *regs)
>> __attribute__ ((regparm(3)));
>> +#endif
>
> Is it an issue with this declaration? I think that you should take care
> about grub-core/kern/i386/int.S. So, relevant Makefile should be
> updated instead of this declaration.
I'll have a try. I just remember I struggled a lot with this issue
when writing the patches.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 04/18] xen: prepare common code for Xen PVH support
2018-10-18 15:39 ` Juergen Gross
@ 2018-10-19 6:36 ` Juergen Gross
2018-10-19 6:36 ` [Xen-devel] " Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 6:36 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 18/10/2018 17:39, Juergen Gross wrote:
> On 18/10/2018 16:59, Daniel Kiper wrote:
>> On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote:
>>> Some common code needs to be special cased for Xen PVH mode. This hits
>>> mostly Xen PV mode specific areas.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>> grub-core/kern/i386/tsc.c | 2 +-
>>> include/grub/i386/pc/int.h | 3 +++
>>> include/grub/i386/tsc.h | 2 +-
>>> include/grub/i386/xen/hypercall.h | 5 ++++-
>>> include/grub/kernel.h | 4 +++-
>>> 5 files changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
>>> index f266eb131..43fee3a13 100644
>>> --- a/grub-core/kern/i386/tsc.c
>>> +++ b/grub-core/kern/i386/tsc.c
>>> @@ -65,7 +65,7 @@ grub_tsc_init (void)
>>>
>>> tsc_boot_time = grub_get_tsc ();
>>>
>>> -#ifdef GRUB_MACHINE_XEN
>>> +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
>>
>> s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/
>
> Okay.
>
>>
>>> (void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
>>> #elif defined (GRUB_MACHINE_EFI)
>>> (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
>>> diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
>>> index 16a53e4fe..46fb1e397 100644
>>> --- a/include/grub/i386/pc/int.h
>>> +++ b/include/grub/i386/pc/int.h
>>> @@ -51,9 +51,12 @@ struct grub_bios_int_registers
>>> #define GRUB_CPU_INT_FLAGS_DEFAULT 0
>>> #endif
>>>
>>> +#ifndef GRUB_MACHINE_XENPVH
>>> void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
>>> struct grub_bios_int_registers *regs)
>>> __attribute__ ((regparm(3)));
>>> +#endif
>>
>> Is it an issue with this declaration? I think that you should take care
>> about grub-core/kern/i386/int.S. So, relevant Makefile should be
>> updated instead of this declaration.
>
> I'll have a try. I just remember I struggled a lot with this issue
> when writing the patches.
Ah, now I've found the problem:
I'm including grub/i386/pc/int.h from grub/i386/xenpvh/int.h in order
to avoid having to redefine all the macros and structs in that file.
Unfortunately the EXPORT_FUNC() will make the build fail as in Xen-PVH
I don't have the symbol grub_bios_interrupt available.
I see the following solutions:
1. keep the patch as it is now
2. duplicate grub/i386/pc/int.h in grub/i386/xenpvh/int.h without
EXPORT_FUNC (grub_bios_interrupt)
3. add a dummy grub_bios_interrupt entry in Xen-PVH code
4. split grub/i386/pc/int.h into int_types.h and int.h with
int_types.h containing the stuff I need for Xen-PVH and include
int_types.h from grub/i386/pc/int.h and grub/i386/xenpvh/int.h
(grub/i386/pc/int.h would contain the EXPORT_FUNC then)
What is your preference?
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 04/18] xen: prepare common code for Xen PVH support
2018-10-18 15:39 ` Juergen Gross
2018-10-19 6:36 ` Juergen Gross
@ 2018-10-19 6:36 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 6:36 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 18/10/2018 17:39, Juergen Gross wrote:
> On 18/10/2018 16:59, Daniel Kiper wrote:
>> On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote:
>>> Some common code needs to be special cased for Xen PVH mode. This hits
>>> mostly Xen PV mode specific areas.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>> grub-core/kern/i386/tsc.c | 2 +-
>>> include/grub/i386/pc/int.h | 3 +++
>>> include/grub/i386/tsc.h | 2 +-
>>> include/grub/i386/xen/hypercall.h | 5 ++++-
>>> include/grub/kernel.h | 4 +++-
>>> 5 files changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
>>> index f266eb131..43fee3a13 100644
>>> --- a/grub-core/kern/i386/tsc.c
>>> +++ b/grub-core/kern/i386/tsc.c
>>> @@ -65,7 +65,7 @@ grub_tsc_init (void)
>>>
>>> tsc_boot_time = grub_get_tsc ();
>>>
>>> -#ifdef GRUB_MACHINE_XEN
>>> +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
>>
>> s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/
>
> Okay.
>
>>
>>> (void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
>>> #elif defined (GRUB_MACHINE_EFI)
>>> (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
>>> diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
>>> index 16a53e4fe..46fb1e397 100644
>>> --- a/include/grub/i386/pc/int.h
>>> +++ b/include/grub/i386/pc/int.h
>>> @@ -51,9 +51,12 @@ struct grub_bios_int_registers
>>> #define GRUB_CPU_INT_FLAGS_DEFAULT 0
>>> #endif
>>>
>>> +#ifndef GRUB_MACHINE_XENPVH
>>> void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
>>> struct grub_bios_int_registers *regs)
>>> __attribute__ ((regparm(3)));
>>> +#endif
>>
>> Is it an issue with this declaration? I think that you should take care
>> about grub-core/kern/i386/int.S. So, relevant Makefile should be
>> updated instead of this declaration.
>
> I'll have a try. I just remember I struggled a lot with this issue
> when writing the patches.
Ah, now I've found the problem:
I'm including grub/i386/pc/int.h from grub/i386/xenpvh/int.h in order
to avoid having to redefine all the macros and structs in that file.
Unfortunately the EXPORT_FUNC() will make the build fail as in Xen-PVH
I don't have the symbol grub_bios_interrupt available.
I see the following solutions:
1. keep the patch as it is now
2. duplicate grub/i386/pc/int.h in grub/i386/xenpvh/int.h without
EXPORT_FUNC (grub_bios_interrupt)
3. add a dummy grub_bios_interrupt entry in Xen-PVH code
4. split grub/i386/pc/int.h into int_types.h and int.h with
int_types.h containing the stuff I need for Xen-PVH and include
int_types.h from grub/i386/pc/int.h and grub/i386/xenpvh/int.h
(grub/i386/pc/int.h would contain the EXPORT_FUNC then)
What is your preference?
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 04/18] xen: prepare common code for Xen PVH support
2018-10-18 14:59 ` Daniel Kiper
(?)
(?)
@ 2018-10-18 15:39 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 15:39 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 18/10/2018 16:59, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:03PM +0200, Juergen Gross wrote:
>> Some common code needs to be special cased for Xen PVH mode. This hits
>> mostly Xen PV mode specific areas.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/tsc.c | 2 +-
>> include/grub/i386/pc/int.h | 3 +++
>> include/grub/i386/tsc.h | 2 +-
>> include/grub/i386/xen/hypercall.h | 5 ++++-
>> include/grub/kernel.h | 4 +++-
>> 5 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
>> index f266eb131..43fee3a13 100644
>> --- a/grub-core/kern/i386/tsc.c
>> +++ b/grub-core/kern/i386/tsc.c
>> @@ -65,7 +65,7 @@ grub_tsc_init (void)
>>
>> tsc_boot_time = grub_get_tsc ();
>>
>> -#ifdef GRUB_MACHINE_XEN
>> +#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
>
> s/GRUB_MACHINE_XENPVH/GRUB_MACHINE_XEN_PVH/
Okay.
>
>> (void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
>> #elif defined (GRUB_MACHINE_EFI)
>> (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
>> diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
>> index 16a53e4fe..46fb1e397 100644
>> --- a/include/grub/i386/pc/int.h
>> +++ b/include/grub/i386/pc/int.h
>> @@ -51,9 +51,12 @@ struct grub_bios_int_registers
>> #define GRUB_CPU_INT_FLAGS_DEFAULT 0
>> #endif
>>
>> +#ifndef GRUB_MACHINE_XENPVH
>> void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
>> struct grub_bios_int_registers *regs)
>> __attribute__ ((regparm(3)));
>> +#endif
>
> Is it an issue with this declaration? I think that you should take care
> about grub-core/kern/i386/int.S. So, relevant Makefile should be
> updated instead of this declaration.
I'll have a try. I just remember I struggled a lot with this issue
when writing the patches.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 04/18] xen: prepare common code for Xen PVH support
2018-10-09 11:02 ` Juergen Gross
` (4 preceding siblings ...)
(?)
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Some common code needs to be special cased for Xen PVH mode. This hits
mostly Xen PV mode specific areas.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/tsc.c | 2 +-
include/grub/i386/pc/int.h | 3 +++
include/grub/i386/tsc.h | 2 +-
include/grub/i386/xen/hypercall.h | 5 ++++-
include/grub/kernel.h | 4 +++-
5 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
index f266eb131..43fee3a13 100644
--- a/grub-core/kern/i386/tsc.c
+++ b/grub-core/kern/i386/tsc.c
@@ -65,7 +65,7 @@ grub_tsc_init (void)
tsc_boot_time = grub_get_tsc ();
-#ifdef GRUB_MACHINE_XEN
+#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XENPVH)
(void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
#elif defined (GRUB_MACHINE_EFI)
(void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
diff --git a/include/grub/i386/pc/int.h b/include/grub/i386/pc/int.h
index 16a53e4fe..46fb1e397 100644
--- a/include/grub/i386/pc/int.h
+++ b/include/grub/i386/pc/int.h
@@ -51,9 +51,12 @@ struct grub_bios_int_registers
#define GRUB_CPU_INT_FLAGS_DEFAULT 0
#endif
+#ifndef GRUB_MACHINE_XENPVH
void EXPORT_FUNC (grub_bios_interrupt) (grub_uint8_t intno,
struct grub_bios_int_registers *regs)
__attribute__ ((regparm(3)));
+#endif
+
struct grub_i386_idt
{
grub_uint16_t limit;
diff --git a/include/grub/i386/tsc.h b/include/grub/i386/tsc.h
index a0aa2c573..8fe1dafa4 100644
--- a/include/grub/i386/tsc.h
+++ b/include/grub/i386/tsc.h
@@ -54,7 +54,7 @@ grub_get_tsc (void)
static __inline int
grub_cpu_is_tsc_supported (void)
{
-#ifndef GRUB_MACHINE_XEN
+#if !defined(GRUB_MACHINE_XEN) && !defined(GRUB_MACHINE_XENPVH)
grub_uint32_t a,b,c,d;
if (! grub_cpu_is_cpuid_supported ())
return 0;
diff --git a/include/grub/i386/xen/hypercall.h b/include/grub/i386/xen/hypercall.h
index 198ee94af..4e4c12a49 100644
--- a/include/grub/i386/xen/hypercall.h
+++ b/include/grub/i386/xen/hypercall.h
@@ -26,7 +26,10 @@ EXPORT_FUNC (grub_xen_hypercall) (grub_uint32_t callno, grub_uint32_t a0,
grub_uint32_t a1, grub_uint32_t a2,
grub_uint32_t a3, grub_uint32_t a4,
grub_uint32_t a5)
-__attribute__ ((regparm (3), cdecl));
+#ifdef GRUB_MACHINE_XEN
+ __attribute__ ((regparm (3), cdecl))
+#endif
+ ;
static inline int
grub_xen_sched_op (int cmd, void *arg)
diff --git a/include/grub/kernel.h b/include/grub/kernel.h
index ecd88ca72..b0f1e923c 100644
--- a/include/grub/kernel.h
+++ b/include/grub/kernel.h
@@ -79,7 +79,9 @@ struct grub_module_info64
#if defined (GRUB_MACHINE_PCBIOS) || defined (GRUB_MACHINE_COREBOOT) \
|| defined (GRUB_MACHINE_MULTIBOOT) || defined (GRUB_MACHINE_MIPS_QEMU_MIPS) \
|| defined (GRUB_MACHINE_MIPS_LOONGSON) || defined (GRUB_MACHINE_ARC) \
- || (defined (__sparc__) && defined (GRUB_MACHINE_IEEE1275)) || defined (GRUB_MACHINE_UBOOT) || defined (GRUB_MACHINE_XEN)
+ || (defined (__sparc__) && defined (GRUB_MACHINE_IEEE1275)) \
+ || defined (GRUB_MACHINE_UBOOT) || defined (GRUB_MACHINE_XEN) \
+ || defined(GRUB_MACHINE_XENPVH)
/* FIXME: stack is between 2 heap regions. Move it. */
#define GRUB_KERNEL_PRELOAD_SPACE_REUSABLE 1
#endif
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 05/18] xen: add some dummy headers for PVH mode
2018-10-09 11:02 ` Juergen Gross
` (5 preceding siblings ...)
(?)
@ 2018-10-09 11:03 ` Juergen Gross
2018-10-18 15:19 ` Daniel Kiper
-1 siblings, 1 reply; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Xen PVH mode needs some headers including the common i386 headers.
Add those to the tree.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
include/grub/i386/xenpvh/boot.h | 1 +
include/grub/i386/xenpvh/console.h | 1 +
include/grub/i386/xenpvh/int.h | 1 +
include/grub/i386/xenpvh/memory.h | 1 +
include/grub/i386/xenpvh/time.h | 1 +
5 files changed, 5 insertions(+)
create mode 100644 include/grub/i386/xenpvh/boot.h
create mode 100644 include/grub/i386/xenpvh/console.h
create mode 100644 include/grub/i386/xenpvh/int.h
create mode 100644 include/grub/i386/xenpvh/memory.h
create mode 100644 include/grub/i386/xenpvh/time.h
diff --git a/include/grub/i386/xenpvh/boot.h b/include/grub/i386/xenpvh/boot.h
new file mode 100644
index 000000000..6cd23aa83
--- /dev/null
+++ b/include/grub/i386/xenpvh/boot.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/boot.h>
diff --git a/include/grub/i386/xenpvh/console.h b/include/grub/i386/xenpvh/console.h
new file mode 100644
index 000000000..305a46d8e
--- /dev/null
+++ b/include/grub/i386/xenpvh/console.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/console.h>
diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h
new file mode 100644
index 000000000..6f9d14a81
--- /dev/null
+++ b/include/grub/i386/xenpvh/int.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/int.h>
diff --git a/include/grub/i386/xenpvh/memory.h b/include/grub/i386/xenpvh/memory.h
new file mode 100644
index 000000000..8dd6f7c8c
--- /dev/null
+++ b/include/grub/i386/xenpvh/memory.h
@@ -0,0 +1 @@
+#include <grub/i386/coreboot/memory.h>
diff --git a/include/grub/i386/xenpvh/time.h b/include/grub/i386/xenpvh/time.h
new file mode 100644
index 000000000..2298ee8f4
--- /dev/null
+++ b/include/grub/i386/xenpvh/time.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/time.h>
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 05/18] xen: add some dummy headers for PVH mode
2018-10-09 11:03 ` [PATCH v2 05/18] xen: add some dummy headers for PVH mode Juergen Gross
@ 2018-10-18 15:19 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 15:19 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:04PM +0200, Juergen Gross wrote:
> Xen PVH mode needs some headers including the common i386 headers.
> Add those to the tree.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> include/grub/i386/xenpvh/boot.h | 1 +
> include/grub/i386/xenpvh/console.h | 1 +
> include/grub/i386/xenpvh/int.h | 1 +
> include/grub/i386/xenpvh/memory.h | 1 +
> include/grub/i386/xenpvh/time.h | 1 +
> 5 files changed, 5 insertions(+)
> create mode 100644 include/grub/i386/xenpvh/boot.h
> create mode 100644 include/grub/i386/xenpvh/console.h
> create mode 100644 include/grub/i386/xenpvh/int.h
> create mode 100644 include/grub/i386/xenpvh/memory.h
> create mode 100644 include/grub/i386/xenpvh/time.h
>
> diff --git a/include/grub/i386/xenpvh/boot.h b/include/grub/i386/xenpvh/boot.h
> new file mode 100644
> index 000000000..6cd23aa83
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/boot.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/boot.h>
> diff --git a/include/grub/i386/xenpvh/console.h b/include/grub/i386/xenpvh/console.h
> new file mode 100644
> index 000000000..305a46d8e
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/console.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/console.h>
> diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h
> new file mode 100644
> index 000000000..6f9d14a81
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/int.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/int.h>
> diff --git a/include/grub/i386/xenpvh/memory.h b/include/grub/i386/xenpvh/memory.h
> new file mode 100644
> index 000000000..8dd6f7c8c
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/memory.h
> @@ -0,0 +1 @@
> +#include <grub/i386/coreboot/memory.h>
> diff --git a/include/grub/i386/xenpvh/time.h b/include/grub/i386/xenpvh/time.h
> new file mode 100644
> index 000000000..2298ee8f4
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/time.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/time.h>
I do not understand why we need these files. And commit message just states
just that we need them. However, it says nothing why... So, why? Who will
use them?
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 05/18] xen: add some dummy headers for PVH mode
@ 2018-10-18 15:19 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 15:19 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:04PM +0200, Juergen Gross wrote:
> Xen PVH mode needs some headers including the common i386 headers.
> Add those to the tree.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> include/grub/i386/xenpvh/boot.h | 1 +
> include/grub/i386/xenpvh/console.h | 1 +
> include/grub/i386/xenpvh/int.h | 1 +
> include/grub/i386/xenpvh/memory.h | 1 +
> include/grub/i386/xenpvh/time.h | 1 +
> 5 files changed, 5 insertions(+)
> create mode 100644 include/grub/i386/xenpvh/boot.h
> create mode 100644 include/grub/i386/xenpvh/console.h
> create mode 100644 include/grub/i386/xenpvh/int.h
> create mode 100644 include/grub/i386/xenpvh/memory.h
> create mode 100644 include/grub/i386/xenpvh/time.h
>
> diff --git a/include/grub/i386/xenpvh/boot.h b/include/grub/i386/xenpvh/boot.h
> new file mode 100644
> index 000000000..6cd23aa83
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/boot.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/boot.h>
> diff --git a/include/grub/i386/xenpvh/console.h b/include/grub/i386/xenpvh/console.h
> new file mode 100644
> index 000000000..305a46d8e
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/console.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/console.h>
> diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h
> new file mode 100644
> index 000000000..6f9d14a81
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/int.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/int.h>
> diff --git a/include/grub/i386/xenpvh/memory.h b/include/grub/i386/xenpvh/memory.h
> new file mode 100644
> index 000000000..8dd6f7c8c
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/memory.h
> @@ -0,0 +1 @@
> +#include <grub/i386/coreboot/memory.h>
> diff --git a/include/grub/i386/xenpvh/time.h b/include/grub/i386/xenpvh/time.h
> new file mode 100644
> index 000000000..2298ee8f4
> --- /dev/null
> +++ b/include/grub/i386/xenpvh/time.h
> @@ -0,0 +1 @@
> +#include <grub/i386/pc/time.h>
I do not understand why we need these files. And commit message just states
just that we need them. However, it says nothing why... So, why? Who will
use them?
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 05/18] xen: add some dummy headers for PVH mode
2018-10-18 15:19 ` Daniel Kiper
(?)
@ 2018-10-18 15:40 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 15:40 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, xen-devel, phcoder, hans
On 18/10/2018 17:19, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:04PM +0200, Juergen Gross wrote:
>> Xen PVH mode needs some headers including the common i386 headers.
>> Add those to the tree.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> include/grub/i386/xenpvh/boot.h | 1 +
>> include/grub/i386/xenpvh/console.h | 1 +
>> include/grub/i386/xenpvh/int.h | 1 +
>> include/grub/i386/xenpvh/memory.h | 1 +
>> include/grub/i386/xenpvh/time.h | 1 +
>> 5 files changed, 5 insertions(+)
>> create mode 100644 include/grub/i386/xenpvh/boot.h
>> create mode 100644 include/grub/i386/xenpvh/console.h
>> create mode 100644 include/grub/i386/xenpvh/int.h
>> create mode 100644 include/grub/i386/xenpvh/memory.h
>> create mode 100644 include/grub/i386/xenpvh/time.h
>>
>> diff --git a/include/grub/i386/xenpvh/boot.h b/include/grub/i386/xenpvh/boot.h
>> new file mode 100644
>> index 000000000..6cd23aa83
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/boot.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/boot.h>
>> diff --git a/include/grub/i386/xenpvh/console.h b/include/grub/i386/xenpvh/console.h
>> new file mode 100644
>> index 000000000..305a46d8e
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/console.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/console.h>
>> diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h
>> new file mode 100644
>> index 000000000..6f9d14a81
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/int.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/int.h>
>> diff --git a/include/grub/i386/xenpvh/memory.h b/include/grub/i386/xenpvh/memory.h
>> new file mode 100644
>> index 000000000..8dd6f7c8c
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/memory.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/coreboot/memory.h>
>> diff --git a/include/grub/i386/xenpvh/time.h b/include/grub/i386/xenpvh/time.h
>> new file mode 100644
>> index 000000000..2298ee8f4
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/time.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/time.h>
>
> I do not understand why we need these files. And commit message just states
> just that we need them. However, it says nothing why... So, why? Who will
> use them?
Any source including grub/machine/*.h
I'll make the commit message more verbose in this regard.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 05/18] xen: add some dummy headers for PVH mode
2018-10-18 15:19 ` Daniel Kiper
(?)
(?)
@ 2018-10-18 15:40 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-18 15:40 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 18/10/2018 17:19, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:04PM +0200, Juergen Gross wrote:
>> Xen PVH mode needs some headers including the common i386 headers.
>> Add those to the tree.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> include/grub/i386/xenpvh/boot.h | 1 +
>> include/grub/i386/xenpvh/console.h | 1 +
>> include/grub/i386/xenpvh/int.h | 1 +
>> include/grub/i386/xenpvh/memory.h | 1 +
>> include/grub/i386/xenpvh/time.h | 1 +
>> 5 files changed, 5 insertions(+)
>> create mode 100644 include/grub/i386/xenpvh/boot.h
>> create mode 100644 include/grub/i386/xenpvh/console.h
>> create mode 100644 include/grub/i386/xenpvh/int.h
>> create mode 100644 include/grub/i386/xenpvh/memory.h
>> create mode 100644 include/grub/i386/xenpvh/time.h
>>
>> diff --git a/include/grub/i386/xenpvh/boot.h b/include/grub/i386/xenpvh/boot.h
>> new file mode 100644
>> index 000000000..6cd23aa83
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/boot.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/boot.h>
>> diff --git a/include/grub/i386/xenpvh/console.h b/include/grub/i386/xenpvh/console.h
>> new file mode 100644
>> index 000000000..305a46d8e
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/console.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/console.h>
>> diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h
>> new file mode 100644
>> index 000000000..6f9d14a81
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/int.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/int.h>
>> diff --git a/include/grub/i386/xenpvh/memory.h b/include/grub/i386/xenpvh/memory.h
>> new file mode 100644
>> index 000000000..8dd6f7c8c
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/memory.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/coreboot/memory.h>
>> diff --git a/include/grub/i386/xenpvh/time.h b/include/grub/i386/xenpvh/time.h
>> new file mode 100644
>> index 000000000..2298ee8f4
>> --- /dev/null
>> +++ b/include/grub/i386/xenpvh/time.h
>> @@ -0,0 +1 @@
>> +#include <grub/i386/pc/time.h>
>
> I do not understand why we need these files. And commit message just states
> just that we need them. However, it says nothing why... So, why? Who will
> use them?
Any source including grub/machine/*.h
I'll make the commit message more verbose in this regard.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 05/18] xen: add some dummy headers for PVH mode
2018-10-09 11:02 ` Juergen Gross
` (6 preceding siblings ...)
(?)
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Xen PVH mode needs some headers including the common i386 headers.
Add those to the tree.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
include/grub/i386/xenpvh/boot.h | 1 +
include/grub/i386/xenpvh/console.h | 1 +
include/grub/i386/xenpvh/int.h | 1 +
include/grub/i386/xenpvh/memory.h | 1 +
include/grub/i386/xenpvh/time.h | 1 +
5 files changed, 5 insertions(+)
create mode 100644 include/grub/i386/xenpvh/boot.h
create mode 100644 include/grub/i386/xenpvh/console.h
create mode 100644 include/grub/i386/xenpvh/int.h
create mode 100644 include/grub/i386/xenpvh/memory.h
create mode 100644 include/grub/i386/xenpvh/time.h
diff --git a/include/grub/i386/xenpvh/boot.h b/include/grub/i386/xenpvh/boot.h
new file mode 100644
index 000000000..6cd23aa83
--- /dev/null
+++ b/include/grub/i386/xenpvh/boot.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/boot.h>
diff --git a/include/grub/i386/xenpvh/console.h b/include/grub/i386/xenpvh/console.h
new file mode 100644
index 000000000..305a46d8e
--- /dev/null
+++ b/include/grub/i386/xenpvh/console.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/console.h>
diff --git a/include/grub/i386/xenpvh/int.h b/include/grub/i386/xenpvh/int.h
new file mode 100644
index 000000000..6f9d14a81
--- /dev/null
+++ b/include/grub/i386/xenpvh/int.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/int.h>
diff --git a/include/grub/i386/xenpvh/memory.h b/include/grub/i386/xenpvh/memory.h
new file mode 100644
index 000000000..8dd6f7c8c
--- /dev/null
+++ b/include/grub/i386/xenpvh/memory.h
@@ -0,0 +1 @@
+#include <grub/i386/coreboot/memory.h>
diff --git a/include/grub/i386/xenpvh/time.h b/include/grub/i386/xenpvh/time.h
new file mode 100644
index 000000000..2298ee8f4
--- /dev/null
+++ b/include/grub/i386/xenpvh/time.h
@@ -0,0 +1 @@
+#include <grub/i386/pc/time.h>
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 06/18] xen: rearrange xen/init.c to prepare it for Xen PVH mode
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Rearrange grub-core/kern/xen/init.c to prepare adding PVH mode support
to it. This includes putting some code under #ifdef GRUB_MACHINE_XEN
as it will not be used when running as PVH.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/xen/init.c | 60 +++++++++++++++++++++++++++--------------------
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 29f5bc23d..10007b411 100644
--- a/grub-core/kern/xen/init.c
+++ b/grub-core/kern/xen/init.c
@@ -41,9 +41,11 @@ grub_size_t grub_xen_n_allocated_shared_pages;
static grub_xen_mfn_t
grub_xen_ptr2mfn (void *ptr)
{
+#ifdef GRUB_MACHINE_XEN
grub_xen_mfn_t *mfn_list =
(grub_xen_mfn_t *) grub_xen_start_page_addr->mfn_list;
return mfn_list[(grub_addr_t) ptr >> GRUB_XEN_LOG_PAGE_SIZE];
+#endif
}
void *
@@ -104,18 +106,6 @@ grub_machine_get_bootlocation (char **device __attribute__ ((unused)),
{
}
-static grub_uint8_t window[GRUB_XEN_PAGE_SIZE]
- __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
-
-#ifdef __x86_64__
-#define NUMBER_OF_LEVELS 4
-#else
-#define NUMBER_OF_LEVELS 3
-#endif
-
-#define LOG_POINTERS_PER_PAGE 9
-#define POINTERS_PER_PAGE (1 << LOG_POINTERS_PER_PAGE)
-
void
grub_xen_store_send (const void *buf_, grub_size_t len)
{
@@ -337,6 +327,19 @@ grub_xen_setup_gnttab (void)
grub_xen_grant_table_op (GNTTABOP_setup_table, &gnttab_setup, 1);
}
+#ifdef GRUB_MACHINE_XEN
+static grub_uint8_t window[GRUB_XEN_PAGE_SIZE]
+ __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
+
+#ifdef __x86_64__
+#define NUMBER_OF_LEVELS 4
+#else
+#define NUMBER_OF_LEVELS 3
+#endif
+
+#define LOG_POINTERS_PER_PAGE 9
+#define POINTERS_PER_PAGE (1 << LOG_POINTERS_PER_PAGE)
+
#define MAX_N_UNUSABLE_PAGES 4
static int
@@ -529,13 +532,30 @@ map_all_pages (void)
grub_mm_init_region ((void *) heap_start, heap_end - heap_start);
}
+grub_err_t
+grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
+{
+ grub_uint64_t total_pages = grub_xen_start_page_addr->nr_pages;
+ grub_uint64_t usable_pages = grub_xen_start_page_addr->pt_base >> 12;
+ if (hook (0, page2offset (usable_pages), GRUB_MEMORY_AVAILABLE, hook_data))
+ return GRUB_ERR_NONE;
+
+ hook (page2offset (usable_pages), page2offset (total_pages - usable_pages),
+ GRUB_MEMORY_RESERVED, hook_data);
+
+ return GRUB_ERR_NONE;
+}
+#endif
+
extern char _end[];
void
grub_machine_init (void)
{
+#ifdef GRUB_MACHINE_XEN
#ifdef __i386__
grub_xen_vm_assist (VMASST_CMD_enable, VMASST_TYPE_pae_extended_cr3);
+#endif
#endif
grub_modbase = ALIGN_UP ((grub_addr_t) _end
@@ -544,7 +564,9 @@ grub_machine_init (void)
grub_xen_setup_gnttab ();
+#ifdef GRUB_MACHINE_XEN
map_all_pages ();
+#endif
grub_console_init ();
@@ -571,17 +593,3 @@ grub_machine_fini (int flags __attribute__ ((unused)))
grub_xendisk_fini ();
grub_boot_fini ();
}
-
-grub_err_t
-grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
-{
- grub_uint64_t total_pages = grub_xen_start_page_addr->nr_pages;
- grub_uint64_t usable_pages = grub_xen_start_page_addr->pt_base >> 12;
- if (hook (0, page2offset (usable_pages), GRUB_MEMORY_AVAILABLE, hook_data))
- return GRUB_ERR_NONE;
-
- hook (page2offset (usable_pages), page2offset (total_pages - usable_pages),
- GRUB_MEMORY_RESERVED, hook_data);
-
- return GRUB_ERR_NONE;
-}
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 06/18] xen: rearrange xen/init.c to prepare it for Xen PVH mode
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Rearrange grub-core/kern/xen/init.c to prepare adding PVH mode support
to it. This includes putting some code under #ifdef GRUB_MACHINE_XEN
as it will not be used when running as PVH.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/xen/init.c | 60 +++++++++++++++++++++++++++--------------------
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 29f5bc23d..10007b411 100644
--- a/grub-core/kern/xen/init.c
+++ b/grub-core/kern/xen/init.c
@@ -41,9 +41,11 @@ grub_size_t grub_xen_n_allocated_shared_pages;
static grub_xen_mfn_t
grub_xen_ptr2mfn (void *ptr)
{
+#ifdef GRUB_MACHINE_XEN
grub_xen_mfn_t *mfn_list =
(grub_xen_mfn_t *) grub_xen_start_page_addr->mfn_list;
return mfn_list[(grub_addr_t) ptr >> GRUB_XEN_LOG_PAGE_SIZE];
+#endif
}
void *
@@ -104,18 +106,6 @@ grub_machine_get_bootlocation (char **device __attribute__ ((unused)),
{
}
-static grub_uint8_t window[GRUB_XEN_PAGE_SIZE]
- __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
-
-#ifdef __x86_64__
-#define NUMBER_OF_LEVELS 4
-#else
-#define NUMBER_OF_LEVELS 3
-#endif
-
-#define LOG_POINTERS_PER_PAGE 9
-#define POINTERS_PER_PAGE (1 << LOG_POINTERS_PER_PAGE)
-
void
grub_xen_store_send (const void *buf_, grub_size_t len)
{
@@ -337,6 +327,19 @@ grub_xen_setup_gnttab (void)
grub_xen_grant_table_op (GNTTABOP_setup_table, &gnttab_setup, 1);
}
+#ifdef GRUB_MACHINE_XEN
+static grub_uint8_t window[GRUB_XEN_PAGE_SIZE]
+ __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
+
+#ifdef __x86_64__
+#define NUMBER_OF_LEVELS 4
+#else
+#define NUMBER_OF_LEVELS 3
+#endif
+
+#define LOG_POINTERS_PER_PAGE 9
+#define POINTERS_PER_PAGE (1 << LOG_POINTERS_PER_PAGE)
+
#define MAX_N_UNUSABLE_PAGES 4
static int
@@ -529,13 +532,30 @@ map_all_pages (void)
grub_mm_init_region ((void *) heap_start, heap_end - heap_start);
}
+grub_err_t
+grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
+{
+ grub_uint64_t total_pages = grub_xen_start_page_addr->nr_pages;
+ grub_uint64_t usable_pages = grub_xen_start_page_addr->pt_base >> 12;
+ if (hook (0, page2offset (usable_pages), GRUB_MEMORY_AVAILABLE, hook_data))
+ return GRUB_ERR_NONE;
+
+ hook (page2offset (usable_pages), page2offset (total_pages - usable_pages),
+ GRUB_MEMORY_RESERVED, hook_data);
+
+ return GRUB_ERR_NONE;
+}
+#endif
+
extern char _end[];
void
grub_machine_init (void)
{
+#ifdef GRUB_MACHINE_XEN
#ifdef __i386__
grub_xen_vm_assist (VMASST_CMD_enable, VMASST_TYPE_pae_extended_cr3);
+#endif
#endif
grub_modbase = ALIGN_UP ((grub_addr_t) _end
@@ -544,7 +564,9 @@ grub_machine_init (void)
grub_xen_setup_gnttab ();
+#ifdef GRUB_MACHINE_XEN
map_all_pages ();
+#endif
grub_console_init ();
@@ -571,17 +593,3 @@ grub_machine_fini (int flags __attribute__ ((unused)))
grub_xendisk_fini ();
grub_boot_fini ();
}
-
-grub_err_t
-grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
-{
- grub_uint64_t total_pages = grub_xen_start_page_addr->nr_pages;
- grub_uint64_t usable_pages = grub_xen_start_page_addr->pt_base >> 12;
- if (hook (0, page2offset (usable_pages), GRUB_MEMORY_AVAILABLE, hook_data))
- return GRUB_ERR_NONE;
-
- hook (page2offset (usable_pages), page2offset (total_pages - usable_pages),
- GRUB_MEMORY_RESERVED, hook_data);
-
- return GRUB_ERR_NONE;
-}
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 06/18] xen: rearrange xen/init.c to prepare it for Xen PVH mode
2018-10-09 11:03 ` Juergen Gross
@ 2018-10-18 17:55 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 17:55 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:05PM +0200, Juergen Gross wrote:
> Rearrange grub-core/kern/xen/init.c to prepare adding PVH mode support
> to it. This includes putting some code under #ifdef GRUB_MACHINE_XEN
> as it will not be used when running as PVH.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 06/18] xen: rearrange xen/init.c to prepare it for Xen PVH mode
@ 2018-10-18 17:55 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-18 17:55 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:05PM +0200, Juergen Gross wrote:
> Rearrange grub-core/kern/xen/init.c to prepare adding PVH mode support
> to it. This includes putting some code under #ifdef GRUB_MACHINE_XEN
> as it will not be used when running as PVH.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 07/18] xen: add PVH specific defines to offset.h
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
include/grub/offsets.h needs some defines for Xen PVH mode.
Add them. While at it line up the values in the surrounding lines to
start at the same column.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
include/grub/offsets.h | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/include/grub/offsets.h b/include/grub/offsets.h
index 330e4c707..b16353163 100644
--- a/include/grub/offsets.h
+++ b/include/grub/offsets.h
@@ -36,9 +36,10 @@
#define GRUB_DECOMPRESSOR_I386_PC_MAX_DECOMPRESSOR_SIZE (0x9000-0x8200)
/* The segment where the kernel is loaded. */
-#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
+#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
-#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
+#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
+#define GRUB_KERNEL_I386_XENPVH_LINK_ADDR 0x100000
/* The upper memory area (starting at 640 kiB). */
#define GRUB_MEMORY_I386_PC_UPPER 0xa0000
@@ -101,15 +102,17 @@
#define GRUB_KERNEL_I386_MULTIBOOT_MOD_ALIGN GRUB_KERNEL_I386_COREBOOT_MOD_ALIGN
#define GRUB_KERNEL_X86_64_XEN_MOD_ALIGN 0x8
-#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
+#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
+#define GRUB_KERNEL_I386_XENPVH_MOD_ALIGN 0x8
/* Non-zero value is only needed for PowerMacs. */
-#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
-#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
-#define GRUB_KERNEL_I386_IEEE1275_MOD_GAP 0x0
-#define GRUB_KERNEL_I386_COREBOOT_MOD_GAP 0x0
-#define GRUB_KERNEL_SPARC64_IEEE1275_MOD_GAP 0x0
-#define GRUB_KERNEL_ARM_UBOOT_MOD_GAP 0x0
+#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_XENPVH_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_IEEE1275_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_COREBOOT_MOD_GAP 0x0
+#define GRUB_KERNEL_SPARC64_IEEE1275_MOD_GAP 0x0
+#define GRUB_KERNEL_ARM_UBOOT_MOD_GAP 0x0
#define GRUB_KERNEL_POWERPC_IEEE1275_MOD_ALIGN 0x1000
#define GRUB_KERNEL_SPARC64_IEEE1275_LOG_MOD_ALIGN 3
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v2 07/18] xen: add PVH specific defines to offset.h
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
include/grub/offsets.h needs some defines for Xen PVH mode.
Add them. While at it line up the values in the surrounding lines to
start at the same column.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
include/grub/offsets.h | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/include/grub/offsets.h b/include/grub/offsets.h
index 330e4c707..b16353163 100644
--- a/include/grub/offsets.h
+++ b/include/grub/offsets.h
@@ -36,9 +36,10 @@
#define GRUB_DECOMPRESSOR_I386_PC_MAX_DECOMPRESSOR_SIZE (0x9000-0x8200)
/* The segment where the kernel is loaded. */
-#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
+#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
-#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
+#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
+#define GRUB_KERNEL_I386_XENPVH_LINK_ADDR 0x100000
/* The upper memory area (starting at 640 kiB). */
#define GRUB_MEMORY_I386_PC_UPPER 0xa0000
@@ -101,15 +102,17 @@
#define GRUB_KERNEL_I386_MULTIBOOT_MOD_ALIGN GRUB_KERNEL_I386_COREBOOT_MOD_ALIGN
#define GRUB_KERNEL_X86_64_XEN_MOD_ALIGN 0x8
-#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
+#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
+#define GRUB_KERNEL_I386_XENPVH_MOD_ALIGN 0x8
/* Non-zero value is only needed for PowerMacs. */
-#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
-#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
-#define GRUB_KERNEL_I386_IEEE1275_MOD_GAP 0x0
-#define GRUB_KERNEL_I386_COREBOOT_MOD_GAP 0x0
-#define GRUB_KERNEL_SPARC64_IEEE1275_MOD_GAP 0x0
-#define GRUB_KERNEL_ARM_UBOOT_MOD_GAP 0x0
+#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_XENPVH_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_IEEE1275_MOD_GAP 0x0
+#define GRUB_KERNEL_I386_COREBOOT_MOD_GAP 0x0
+#define GRUB_KERNEL_SPARC64_IEEE1275_MOD_GAP 0x0
+#define GRUB_KERNEL_ARM_UBOOT_MOD_GAP 0x0
#define GRUB_KERNEL_POWERPC_IEEE1275_MOD_ALIGN 0x1000
#define GRUB_KERNEL_SPARC64_IEEE1275_LOG_MOD_ALIGN 3
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread
* Re: [PATCH v2 07/18] xen: add PVH specific defines to offset.h
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-19 11:54 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 11:54 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:06PM +0200, Juergen Gross wrote:
> include/grub/offsets.h needs some defines for Xen PVH mode.
>
> Add them. While at it line up the values in the surrounding lines to
> start at the same column.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> include/grub/offsets.h | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/include/grub/offsets.h b/include/grub/offsets.h
> index 330e4c707..b16353163 100644
> --- a/include/grub/offsets.h
> +++ b/include/grub/offsets.h
> @@ -36,9 +36,10 @@
> #define GRUB_DECOMPRESSOR_I386_PC_MAX_DECOMPRESSOR_SIZE (0x9000-0x8200)
>
> /* The segment where the kernel is loaded. */
> -#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
> +#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
>
> -#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
> +#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
> +#define GRUB_KERNEL_I386_XENPVH_LINK_ADDR 0x100000
s/XENPVH/XEN_PVH/ In general I prefer XEN_PVH instead of XENPVH.
So, please update them all where possible. Not only in this patch.
> /* The upper memory area (starting at 640 kiB). */
> #define GRUB_MEMORY_I386_PC_UPPER 0xa0000
> @@ -101,15 +102,17 @@
> #define GRUB_KERNEL_I386_MULTIBOOT_MOD_ALIGN GRUB_KERNEL_I386_COREBOOT_MOD_ALIGN
>
> #define GRUB_KERNEL_X86_64_XEN_MOD_ALIGN 0x8
> -#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
> +#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
> +#define GRUB_KERNEL_I386_XENPVH_MOD_ALIGN 0x8
Ditto.
> /* Non-zero value is only needed for PowerMacs. */
> -#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
> -#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
> -#define GRUB_KERNEL_I386_IEEE1275_MOD_GAP 0x0
> -#define GRUB_KERNEL_I386_COREBOOT_MOD_GAP 0x0
> -#define GRUB_KERNEL_SPARC64_IEEE1275_MOD_GAP 0x0
> -#define GRUB_KERNEL_ARM_UBOOT_MOD_GAP 0x0
> +#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
> +#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
> +#define GRUB_KERNEL_I386_XENPVH_MOD_GAP 0x0
Ditto.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 07/18] xen: add PVH specific defines to offset.h
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-19 11:54 ` Daniel Kiper
2018-10-19 14:39 ` [Xen-devel] " Juergen Gross
2018-10-19 14:39 ` Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 11:54 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:06PM +0200, Juergen Gross wrote:
> include/grub/offsets.h needs some defines for Xen PVH mode.
>
> Add them. While at it line up the values in the surrounding lines to
> start at the same column.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> include/grub/offsets.h | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/include/grub/offsets.h b/include/grub/offsets.h
> index 330e4c707..b16353163 100644
> --- a/include/grub/offsets.h
> +++ b/include/grub/offsets.h
> @@ -36,9 +36,10 @@
> #define GRUB_DECOMPRESSOR_I386_PC_MAX_DECOMPRESSOR_SIZE (0x9000-0x8200)
>
> /* The segment where the kernel is loaded. */
> -#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
> +#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
>
> -#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
> +#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
> +#define GRUB_KERNEL_I386_XENPVH_LINK_ADDR 0x100000
s/XENPVH/XEN_PVH/ In general I prefer XEN_PVH instead of XENPVH.
So, please update them all where possible. Not only in this patch.
> /* The upper memory area (starting at 640 kiB). */
> #define GRUB_MEMORY_I386_PC_UPPER 0xa0000
> @@ -101,15 +102,17 @@
> #define GRUB_KERNEL_I386_MULTIBOOT_MOD_ALIGN GRUB_KERNEL_I386_COREBOOT_MOD_ALIGN
>
> #define GRUB_KERNEL_X86_64_XEN_MOD_ALIGN 0x8
> -#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
> +#define GRUB_KERNEL_I386_XEN_MOD_ALIGN 0x8
> +#define GRUB_KERNEL_I386_XENPVH_MOD_ALIGN 0x8
Ditto.
> /* Non-zero value is only needed for PowerMacs. */
> -#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
> -#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
> -#define GRUB_KERNEL_I386_IEEE1275_MOD_GAP 0x0
> -#define GRUB_KERNEL_I386_COREBOOT_MOD_GAP 0x0
> -#define GRUB_KERNEL_SPARC64_IEEE1275_MOD_GAP 0x0
> -#define GRUB_KERNEL_ARM_UBOOT_MOD_GAP 0x0
> +#define GRUB_KERNEL_X86_64_XEN_MOD_GAP 0x0
> +#define GRUB_KERNEL_I386_XEN_MOD_GAP 0x0
> +#define GRUB_KERNEL_I386_XENPVH_MOD_GAP 0x0
Ditto.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 07/18] xen: add PVH specific defines to offset.h
2018-10-19 11:54 ` Daniel Kiper
@ 2018-10-19 14:39 ` Juergen Gross
2018-10-19 14:39 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 14:39 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/2018 13:54, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:06PM +0200, Juergen Gross wrote:
>> include/grub/offsets.h needs some defines for Xen PVH mode.
>>
>> Add them. While at it line up the values in the surrounding lines to
>> start at the same column.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> include/grub/offsets.h | 21 ++++++++++++---------
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/include/grub/offsets.h b/include/grub/offsets.h
>> index 330e4c707..b16353163 100644
>> --- a/include/grub/offsets.h
>> +++ b/include/grub/offsets.h
>> @@ -36,9 +36,10 @@
>> #define GRUB_DECOMPRESSOR_I386_PC_MAX_DECOMPRESSOR_SIZE (0x9000-0x8200)
>>
>> /* The segment where the kernel is loaded. */
>> -#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
>> +#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
>>
>> -#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
>> +#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
>> +#define GRUB_KERNEL_I386_XENPVH_LINK_ADDR 0x100000
>
> s/XENPVH/XEN_PVH/ In general I prefer XEN_PVH instead of XENPVH.
> So, please update them all where possible. Not only in this patch.
Does this apply to path names as well (e.g. include/grub/i386/xenpvh/) ?
Or do you mean macros/symbols only?
BTW: if yes, this would affect the visible platform name, too.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 07/18] xen: add PVH specific defines to offset.h
2018-10-19 11:54 ` Daniel Kiper
2018-10-19 14:39 ` [Xen-devel] " Juergen Gross
@ 2018-10-19 14:39 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 14:39 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/2018 13:54, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:06PM +0200, Juergen Gross wrote:
>> include/grub/offsets.h needs some defines for Xen PVH mode.
>>
>> Add them. While at it line up the values in the surrounding lines to
>> start at the same column.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> include/grub/offsets.h | 21 ++++++++++++---------
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/include/grub/offsets.h b/include/grub/offsets.h
>> index 330e4c707..b16353163 100644
>> --- a/include/grub/offsets.h
>> +++ b/include/grub/offsets.h
>> @@ -36,9 +36,10 @@
>> #define GRUB_DECOMPRESSOR_I386_PC_MAX_DECOMPRESSOR_SIZE (0x9000-0x8200)
>>
>> /* The segment where the kernel is loaded. */
>> -#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
>> +#define GRUB_BOOT_I386_PC_KERNEL_SEG 0x800
>>
>> -#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
>> +#define GRUB_KERNEL_I386_PC_LINK_ADDR 0x9000
>> +#define GRUB_KERNEL_I386_XENPVH_LINK_ADDR 0x100000
>
> s/XENPVH/XEN_PVH/ In general I prefer XEN_PVH instead of XENPVH.
> So, please update them all where possible. Not only in this patch.
Does this apply to path names as well (e.g. include/grub/i386/xenpvh/) ?
Or do you mean macros/symbols only?
BTW: if yes, this would affect the visible platform name, too.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Add the hooks to current code needed for Xen PVH.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
grub-core/kern/xen/init.c | 6 ++++++
include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
include/grub/xen.h | 6 ++++++
5 files changed, 107 insertions(+)
create mode 100644 grub-core/kern/i386/xen/pvh.c
create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
create mode 100644 include/grub/i386/xenpvh/kernel.h
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
new file mode 100644
index 000000000..182ef95f9
--- /dev/null
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -0,0 +1,36 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2011 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/kernel.h>
+#include <grub/misc.h>
+#include <grub/memory.h>
+#include <grub/mm.h>
+#include <grub/xen.h>
+#include <grub/machine/kernel.h>
+
+grub_uint64_t grub_rsdp_addr;
+
+void
+grub_xen_setup_pvh (void)
+{
+}
+
+grub_err_t
+grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
+{
+}
diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
new file mode 100644
index 000000000..e18ee5b31
--- /dev/null
+++ b/grub-core/kern/i386/xen/startup_pvh.S
@@ -0,0 +1,29 @@
+/* startup.S - bootstrap GRUB itself */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2013 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <config.h>
+#include <grub/symbol.h>
+
+ .file "startup_pvh.S"
+ .text
+
+/* Saved pointer to start info structure. */
+ .globl pvh_start_info
+pvh_start_info:
+ .long 0
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 10007b411..be71eee90 100644
--- a/grub-core/kern/xen/init.c
+++ b/grub-core/kern/xen/init.c
@@ -45,6 +45,8 @@ grub_xen_ptr2mfn (void *ptr)
grub_xen_mfn_t *mfn_list =
(grub_xen_mfn_t *) grub_xen_start_page_addr->mfn_list;
return mfn_list[(grub_addr_t) ptr >> GRUB_XEN_LOG_PAGE_SIZE];
+#else
+ return (grub_addr_t) ptr >> GRUB_XEN_LOG_PAGE_SIZE;
#endif
}
@@ -562,6 +564,10 @@ grub_machine_init (void)
+ GRUB_KERNEL_MACHINE_MOD_GAP,
GRUB_KERNEL_MACHINE_MOD_ALIGN);
+#ifdef GRUB_MACHINE_XENPVH
+ grub_xen_setup_pvh ();
+#endif
+
grub_xen_setup_gnttab ();
#ifdef GRUB_MACHINE_XEN
diff --git a/include/grub/i386/xenpvh/kernel.h b/include/grub/i386/xenpvh/kernel.h
new file mode 100644
index 000000000..7d4775dc3
--- /dev/null
+++ b/include/grub/i386/xenpvh/kernel.h
@@ -0,0 +1,30 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2002,2005,2006,2007,2008,2009 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef GRUB_KERNEL_MACHINE_HEADER
+#define GRUB_KERNEL_MACHINE_HEADER 1
+
+#ifndef ASM_FILE
+
+#define GRUB_KERNEL_USE_RSDP_ADDR 1
+
+extern grub_uint64_t EXPORT_VAR(grub_rsdp_addr);
+
+#endif /* ! ASM_FILE */
+
+#endif /* GRUB_KERNEL_MACHINE_HEADER */
diff --git a/include/grub/xen.h b/include/grub/xen.h
index c31cc10c7..86eb29a44 100644
--- a/include/grub/xen.h
+++ b/include/grub/xen.h
@@ -43,6 +43,7 @@ typedef grub_uint64_t uint64_t;
#include <xen/sched.h>
#include <xen/grant_table.h>
+#include <xen/hvm/start_info.h>
#include <xen/io/console.h>
#include <xen/io/xs_wire.h>
#include <xen/io/xenbus.h>
@@ -95,6 +96,11 @@ typedef grub_uint64_t grub_xen_mfn_t;
typedef grub_uint32_t grub_xen_mfn_t;
#endif
typedef unsigned int grub_xen_evtchn_t;
+
+#ifdef GRUB_MACHINE_XENPVH
+extern struct hvm_start_info *pvh_start_info;
+void grub_xen_setup_pvh (void);
+#endif
#endif
#endif
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 08/18] xen: add basic hooks for PVH in current code
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Add the hooks to current code needed for Xen PVH.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
grub-core/kern/xen/init.c | 6 ++++++
include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
include/grub/xen.h | 6 ++++++
5 files changed, 107 insertions(+)
create mode 100644 grub-core/kern/i386/xen/pvh.c
create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
create mode 100644 include/grub/i386/xenpvh/kernel.h
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
new file mode 100644
index 000000000..182ef95f9
--- /dev/null
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -0,0 +1,36 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2011 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <grub/kernel.h>
+#include <grub/misc.h>
+#include <grub/memory.h>
+#include <grub/mm.h>
+#include <grub/xen.h>
+#include <grub/machine/kernel.h>
+
+grub_uint64_t grub_rsdp_addr;
+
+void
+grub_xen_setup_pvh (void)
+{
+}
+
+grub_err_t
+grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
+{
+}
diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
new file mode 100644
index 000000000..e18ee5b31
--- /dev/null
+++ b/grub-core/kern/i386/xen/startup_pvh.S
@@ -0,0 +1,29 @@
+/* startup.S - bootstrap GRUB itself */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2013 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <config.h>
+#include <grub/symbol.h>
+
+ .file "startup_pvh.S"
+ .text
+
+/* Saved pointer to start info structure. */
+ .globl pvh_start_info
+pvh_start_info:
+ .long 0
diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
index 10007b411..be71eee90 100644
--- a/grub-core/kern/xen/init.c
+++ b/grub-core/kern/xen/init.c
@@ -45,6 +45,8 @@ grub_xen_ptr2mfn (void *ptr)
grub_xen_mfn_t *mfn_list =
(grub_xen_mfn_t *) grub_xen_start_page_addr->mfn_list;
return mfn_list[(grub_addr_t) ptr >> GRUB_XEN_LOG_PAGE_SIZE];
+#else
+ return (grub_addr_t) ptr >> GRUB_XEN_LOG_PAGE_SIZE;
#endif
}
@@ -562,6 +564,10 @@ grub_machine_init (void)
+ GRUB_KERNEL_MACHINE_MOD_GAP,
GRUB_KERNEL_MACHINE_MOD_ALIGN);
+#ifdef GRUB_MACHINE_XENPVH
+ grub_xen_setup_pvh ();
+#endif
+
grub_xen_setup_gnttab ();
#ifdef GRUB_MACHINE_XEN
diff --git a/include/grub/i386/xenpvh/kernel.h b/include/grub/i386/xenpvh/kernel.h
new file mode 100644
index 000000000..7d4775dc3
--- /dev/null
+++ b/include/grub/i386/xenpvh/kernel.h
@@ -0,0 +1,30 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2002,2005,2006,2007,2008,2009 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef GRUB_KERNEL_MACHINE_HEADER
+#define GRUB_KERNEL_MACHINE_HEADER 1
+
+#ifndef ASM_FILE
+
+#define GRUB_KERNEL_USE_RSDP_ADDR 1
+
+extern grub_uint64_t EXPORT_VAR(grub_rsdp_addr);
+
+#endif /* ! ASM_FILE */
+
+#endif /* GRUB_KERNEL_MACHINE_HEADER */
diff --git a/include/grub/xen.h b/include/grub/xen.h
index c31cc10c7..86eb29a44 100644
--- a/include/grub/xen.h
+++ b/include/grub/xen.h
@@ -43,6 +43,7 @@ typedef grub_uint64_t uint64_t;
#include <xen/sched.h>
#include <xen/grant_table.h>
+#include <xen/hvm/start_info.h>
#include <xen/io/console.h>
#include <xen/io/xs_wire.h>
#include <xen/io/xenbus.h>
@@ -95,6 +96,11 @@ typedef grub_uint64_t grub_xen_mfn_t;
typedef grub_uint32_t grub_xen_mfn_t;
#endif
typedef unsigned int grub_xen_evtchn_t;
+
+#ifdef GRUB_MACHINE_XENPVH
+extern struct hvm_start_info *pvh_start_info;
+void grub_xen_setup_pvh (void);
+#endif
#endif
#endif
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-19 12:05 ` Daniel Kiper
2018-10-19 14:40 ` [Xen-devel] " Juergen Gross
2018-10-19 14:40 ` Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:05 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH.
I am not against the code itself but it would be nice to know why you
add, AIUI, just stubs here which will be filled with proper code later.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-19 12:05 ` Daniel Kiper
@ 2018-10-19 14:40 ` Juergen Gross
2018-10-19 14:40 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 14:40 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/2018 14:05, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
>> Add the hooks to current code needed for Xen PVH.
>
> I am not against the code itself but it would be nice to know why you
> add, AIUI, just stubs here which will be filled with proper code later.
You requested a split of the patch adding PVH stuff. This is the result
of that request.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-19 12:05 ` Daniel Kiper
2018-10-19 14:40 ` [Xen-devel] " Juergen Gross
@ 2018-10-19 14:40 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 14:40 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/2018 14:05, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
>> Add the hooks to current code needed for Xen PVH.
>
> I am not against the code itself but it would be nice to know why you
> add, AIUI, just stubs here which will be filled with proper code later.
You requested a split of the patch adding PVH stuff. This is the result
of that request.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-19 12:05 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:05 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH.
I am not against the code itself but it would be nice to know why you
add, AIUI, just stubs here which will be filled with proper code later.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-09 11:03 ` Juergen Gross
` (2 preceding siblings ...)
(?)
@ 2018-10-19 15:33 ` Roger Pau Monné
2018-10-19 15:52 ` Juergen Gross
2018-10-19 15:52 ` Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 15:33 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
> grub-core/kern/xen/init.c | 6 ++++++
> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
> include/grub/xen.h | 6 ++++++
> 5 files changed, 107 insertions(+)
> create mode 100644 grub-core/kern/i386/xen/pvh.c
> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
> create mode 100644 include/grub/i386/xenpvh/kernel.h
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> new file mode 100644
> index 000000000..182ef95f9
> --- /dev/null
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -0,0 +1,36 @@
> +/*
> + * GRUB -- GRand Unified Bootloader
> + * Copyright (C) 2011 Free Software Foundation, Inc.
Isn't this header (and the ones below) kind of off at least year
wise?
Roger.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-19 15:33 ` [Xen-devel] " Roger Pau Monné
@ 2018-10-19 15:52 ` Juergen Gross
2018-10-22 11:16 ` Daniel Kiper
2018-10-22 11:16 ` [Xen-devel] " Daniel Kiper
2018-10-19 15:52 ` Juergen Gross
1 sibling, 2 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:52 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On 19/10/2018 17:33, Roger Pau Monné wrote:
> On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
>> Add the hooks to current code needed for Xen PVH.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
>> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
>> grub-core/kern/xen/init.c | 6 ++++++
>> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
>> include/grub/xen.h | 6 ++++++
>> 5 files changed, 107 insertions(+)
>> create mode 100644 grub-core/kern/i386/xen/pvh.c
>> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
>> create mode 100644 include/grub/i386/xenpvh/kernel.h
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> new file mode 100644
>> index 000000000..182ef95f9
>> --- /dev/null
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -0,0 +1,36 @@
>> +/*
>> + * GRUB -- GRand Unified Bootloader
>> + * Copyright (C) 2011 Free Software Foundation, Inc.
>
> Isn't this header (and the ones below) kind of off at least year
> wise?
Hmm, only a little bit :-)
Will update.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-19 15:52 ` Juergen Gross
@ 2018-10-22 11:16 ` Daniel Kiper
2018-10-22 11:16 ` [Xen-devel] " Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:16 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel, Roger Pau Monné
On Fri, Oct 19, 2018 at 05:52:44PM +0200, Juergen Gross wrote:
> On 19/10/2018 17:33, Roger Pau Monné wrote:
> > On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
> >> Add the hooks to current code needed for Xen PVH.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
> >> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
> >> grub-core/kern/xen/init.c | 6 ++++++
> >> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
> >> include/grub/xen.h | 6 ++++++
> >> 5 files changed, 107 insertions(+)
> >> create mode 100644 grub-core/kern/i386/xen/pvh.c
> >> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
> >> create mode 100644 include/grub/i386/xenpvh/kernel.h
> >>
> >> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >> new file mode 100644
> >> index 000000000..182ef95f9
> >> --- /dev/null
> >> +++ b/grub-core/kern/i386/xen/pvh.c
> >> @@ -0,0 +1,36 @@
> >> +/*
> >> + * GRUB -- GRand Unified Bootloader
> >> + * Copyright (C) 2011 Free Software Foundation, Inc.
> >
> > Isn't this header (and the ones below) kind of off at least year
> > wise?
>
> Hmm, only a little bit :-)
>
> Will update.
Please do this for all headers in the patchset
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-19 15:52 ` Juergen Gross
2018-10-22 11:16 ` Daniel Kiper
@ 2018-10-22 11:16 ` Daniel Kiper
2018-10-22 11:18 ` Juergen Gross
2018-10-22 11:18 ` Juergen Gross
1 sibling, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:16 UTC (permalink / raw)
To: Juergen Gross; +Cc: Roger Pau Monné, grub-devel, hans, phcoder, xen-devel
On Fri, Oct 19, 2018 at 05:52:44PM +0200, Juergen Gross wrote:
> On 19/10/2018 17:33, Roger Pau Monné wrote:
> > On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
> >> Add the hooks to current code needed for Xen PVH.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
> >> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
> >> grub-core/kern/xen/init.c | 6 ++++++
> >> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
> >> include/grub/xen.h | 6 ++++++
> >> 5 files changed, 107 insertions(+)
> >> create mode 100644 grub-core/kern/i386/xen/pvh.c
> >> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
> >> create mode 100644 include/grub/i386/xenpvh/kernel.h
> >>
> >> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >> new file mode 100644
> >> index 000000000..182ef95f9
> >> --- /dev/null
> >> +++ b/grub-core/kern/i386/xen/pvh.c
> >> @@ -0,0 +1,36 @@
> >> +/*
> >> + * GRUB -- GRand Unified Bootloader
> >> + * Copyright (C) 2011 Free Software Foundation, Inc.
> >
> > Isn't this header (and the ones below) kind of off at least year
> > wise?
>
> Hmm, only a little bit :-)
>
> Will update.
Please do this for all headers in the patchset
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-22 11:16 ` [Xen-devel] " Daniel Kiper
@ 2018-10-22 11:18 ` Juergen Gross
2018-10-22 11:18 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-22 11:18 UTC (permalink / raw)
To: The development of GNU GRUB, Daniel Kiper
Cc: hans, phcoder, xen-devel, Roger Pau Monné
On 22/10/2018 13:16, Daniel Kiper wrote:
> On Fri, Oct 19, 2018 at 05:52:44PM +0200, Juergen Gross wrote:
>> On 19/10/2018 17:33, Roger Pau Monné wrote:
>>> On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
>>>> Add the hooks to current code needed for Xen PVH.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
>>>> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
>>>> grub-core/kern/xen/init.c | 6 ++++++
>>>> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
>>>> include/grub/xen.h | 6 ++++++
>>>> 5 files changed, 107 insertions(+)
>>>> create mode 100644 grub-core/kern/i386/xen/pvh.c
>>>> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
>>>> create mode 100644 include/grub/i386/xenpvh/kernel.h
>>>>
>>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>>>> new file mode 100644
>>>> index 000000000..182ef95f9
>>>> --- /dev/null
>>>> +++ b/grub-core/kern/i386/xen/pvh.c
>>>> @@ -0,0 +1,36 @@
>>>> +/*
>>>> + * GRUB -- GRand Unified Bootloader
>>>> + * Copyright (C) 2011 Free Software Foundation, Inc.
>>>
>>> Isn't this header (and the ones below) kind of off at least year
>>> wise?
>>
>> Hmm, only a little bit :-)
>>
>> Will update.
>
> Please do this for all headers in the patchset
That was my plan :-)
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-22 11:16 ` [Xen-devel] " Daniel Kiper
2018-10-22 11:18 ` Juergen Gross
@ 2018-10-22 11:18 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-22 11:18 UTC (permalink / raw)
To: The development of GNU GRUB, Daniel Kiper
Cc: hans, phcoder, Roger Pau Monné, xen-devel
On 22/10/2018 13:16, Daniel Kiper wrote:
> On Fri, Oct 19, 2018 at 05:52:44PM +0200, Juergen Gross wrote:
>> On 19/10/2018 17:33, Roger Pau Monné wrote:
>>> On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
>>>> Add the hooks to current code needed for Xen PVH.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
>>>> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
>>>> grub-core/kern/xen/init.c | 6 ++++++
>>>> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
>>>> include/grub/xen.h | 6 ++++++
>>>> 5 files changed, 107 insertions(+)
>>>> create mode 100644 grub-core/kern/i386/xen/pvh.c
>>>> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
>>>> create mode 100644 include/grub/i386/xenpvh/kernel.h
>>>>
>>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>>>> new file mode 100644
>>>> index 000000000..182ef95f9
>>>> --- /dev/null
>>>> +++ b/grub-core/kern/i386/xen/pvh.c
>>>> @@ -0,0 +1,36 @@
>>>> +/*
>>>> + * GRUB -- GRand Unified Bootloader
>>>> + * Copyright (C) 2011 Free Software Foundation, Inc.
>>>
>>> Isn't this header (and the ones below) kind of off at least year
>>> wise?
>>
>> Hmm, only a little bit :-)
>>
>> Will update.
>
> Please do this for all headers in the patchset
That was my plan :-)
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-19 15:33 ` [Xen-devel] " Roger Pau Monné
2018-10-19 15:52 ` Juergen Gross
@ 2018-10-19 15:52 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:52 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On 19/10/2018 17:33, Roger Pau Monné wrote:
> On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
>> Add the hooks to current code needed for Xen PVH.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
>> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
>> grub-core/kern/xen/init.c | 6 ++++++
>> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
>> include/grub/xen.h | 6 ++++++
>> 5 files changed, 107 insertions(+)
>> create mode 100644 grub-core/kern/i386/xen/pvh.c
>> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
>> create mode 100644 include/grub/i386/xenpvh/kernel.h
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> new file mode 100644
>> index 000000000..182ef95f9
>> --- /dev/null
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -0,0 +1,36 @@
>> +/*
>> + * GRUB -- GRand Unified Bootloader
>> + * Copyright (C) 2011 Free Software Foundation, Inc.
>
> Isn't this header (and the ones below) kind of off at least year
> wise?
Hmm, only a little bit :-)
Will update.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 08/18] xen: add basic hooks for PVH in current code
2018-10-09 11:03 ` Juergen Gross
` (3 preceding siblings ...)
(?)
@ 2018-10-19 15:33 ` Roger Pau Monné
-1 siblings, 0 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 15:33 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 36 +++++++++++++++++++++++++++++++++++
> grub-core/kern/i386/xen/startup_pvh.S | 29 ++++++++++++++++++++++++++++
> grub-core/kern/xen/init.c | 6 ++++++
> include/grub/i386/xenpvh/kernel.h | 30 +++++++++++++++++++++++++++++
> include/grub/xen.h | 6 ++++++
> 5 files changed, 107 insertions(+)
> create mode 100644 grub-core/kern/i386/xen/pvh.c
> create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
> create mode 100644 include/grub/i386/xenpvh/kernel.h
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> new file mode 100644
> index 000000000..182ef95f9
> --- /dev/null
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -0,0 +1,36 @@
> +/*
> + * GRUB -- GRand Unified Bootloader
> + * Copyright (C) 2011 Free Software Foundation, Inc.
Isn't this header (and the ones below) kind of off at least year
wise?
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 09/18] xen: add PVH boot entry code
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Add the code for the Xen PVH mode boot entry.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
index e18ee5b31..0ddb63b31 100644
--- a/grub-core/kern/i386/xen/startup_pvh.S
+++ b/grub-core/kern/i386/xen/startup_pvh.S
@@ -19,11 +19,61 @@
#include <config.h>
#include <grub/symbol.h>
+#include <grub/machine/memory.h>
.file "startup_pvh.S"
.text
+ .globl start, _start
+ .code32
+start:
+_start:
+ cld
+ lgdt gdtdesc
+ ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
+1:
+ movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
+ mov %eax, %ds
+ mov %eax, %es
+ mov %eax, %ss
+ leal LOCAL(stack_end), %esp
+
+ /* Save address of start info structure. */
+ mov %ebx, pvh_start_info
+ call EXT_C(grub_main)
+ /* Doesn't return. */
+
+ .p2align 3
+gdt:
+ .word 0, 0
+ .byte 0, 0, 0, 0
+
+ /* -- code segment --
+ * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
+ * type = 32bit code execute/read, DPL = 0
+ */
+ .word 0xFFFF, 0
+ .byte 0, 0x9A, 0xCF, 0
+
+ /* -- data segment --
+ * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
+ * type = 32 bit data read/write, DPL = 0
+ */
+ .word 0xFFFF, 0
+ .byte 0, 0x92, 0xCF, 0
+
+ .p2align 3
+/* this is the GDT descriptor */
+gdtdesc:
+ .word 0x17 /* limit */
+ .long gdt /* addr */
+
+ .p2align 2
/* Saved pointer to start info structure. */
.globl pvh_start_info
pvh_start_info:
.long 0
+
+ .bss
+ .space (1 << 22)
+LOCAL(stack_end):
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v2 09/18] xen: add PVH boot entry code
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Add the code for the Xen PVH mode boot entry.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
index e18ee5b31..0ddb63b31 100644
--- a/grub-core/kern/i386/xen/startup_pvh.S
+++ b/grub-core/kern/i386/xen/startup_pvh.S
@@ -19,11 +19,61 @@
#include <config.h>
#include <grub/symbol.h>
+#include <grub/machine/memory.h>
.file "startup_pvh.S"
.text
+ .globl start, _start
+ .code32
+start:
+_start:
+ cld
+ lgdt gdtdesc
+ ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
+1:
+ movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
+ mov %eax, %ds
+ mov %eax, %es
+ mov %eax, %ss
+ leal LOCAL(stack_end), %esp
+
+ /* Save address of start info structure. */
+ mov %ebx, pvh_start_info
+ call EXT_C(grub_main)
+ /* Doesn't return. */
+
+ .p2align 3
+gdt:
+ .word 0, 0
+ .byte 0, 0, 0, 0
+
+ /* -- code segment --
+ * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
+ * type = 32bit code execute/read, DPL = 0
+ */
+ .word 0xFFFF, 0
+ .byte 0, 0x9A, 0xCF, 0
+
+ /* -- data segment --
+ * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
+ * type = 32 bit data read/write, DPL = 0
+ */
+ .word 0xFFFF, 0
+ .byte 0, 0x92, 0xCF, 0
+
+ .p2align 3
+/* this is the GDT descriptor */
+gdtdesc:
+ .word 0x17 /* limit */
+ .long gdt /* addr */
+
+ .p2align 2
/* Saved pointer to start info structure. */
.globl pvh_start_info
pvh_start_info:
.long 0
+
+ .bss
+ .space (1 << 22)
+LOCAL(stack_end):
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread
* Re: [PATCH v2 09/18] xen: add PVH boot entry code
2018-10-09 11:03 ` Juergen Gross
@ 2018-10-19 12:17 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:17 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:08PM +0200, Juergen Gross wrote:
> Add the code for the Xen PVH mode boot entry.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
> index e18ee5b31..0ddb63b31 100644
> --- a/grub-core/kern/i386/xen/startup_pvh.S
> +++ b/grub-core/kern/i386/xen/startup_pvh.S
> @@ -19,11 +19,61 @@
>
> #include <config.h>
> #include <grub/symbol.h>
> +#include <grub/machine/memory.h>
>
> .file "startup_pvh.S"
> .text
> + .globl start, _start
> + .code32
>
> +start:
> +_start:
> + cld
> + lgdt gdtdesc
> + ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
> +1:
> + movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
> + mov %eax, %ds
> + mov %eax, %es
> + mov %eax, %ss
Should not you load null descriptor into %fs and %gs?
Just in case...
> + leal LOCAL(stack_end), %esp
> +
> + /* Save address of start info structure. */
> + mov %ebx, pvh_start_info
> + call EXT_C(grub_main)
> + /* Doesn't return. */
> +
> + .p2align 3
> +gdt:
> + .word 0, 0
> + .byte 0, 0, 0, 0
> +
> + /* -- code segment --
> + * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
> + * type = 32bit code execute/read, DPL = 0
> + */
> + .word 0xFFFF, 0
> + .byte 0, 0x9A, 0xCF, 0
> +
> + /* -- data segment --
> + * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
> + * type = 32 bit data read/write, DPL = 0
> + */
> + .word 0xFFFF, 0
> + .byte 0, 0x92, 0xCF, 0
> +
> + .p2align 3
> +/* this is the GDT descriptor */
> +gdtdesc:
> + .word 0x17 /* limit */
> + .long gdt /* addr */
> +
> + .p2align 2
> /* Saved pointer to start info structure. */
> .globl pvh_start_info
> pvh_start_info:
> .long 0
> +
> + .bss
> + .space (1 << 22)
Hmmm... Why do we need 4 MiB here? If this is really needed then it begs for
a comment. And I would like to see a constant instead of plain number here.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 09/18] xen: add PVH boot entry code
@ 2018-10-19 12:17 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:17 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:08PM +0200, Juergen Gross wrote:
> Add the code for the Xen PVH mode boot entry.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
> index e18ee5b31..0ddb63b31 100644
> --- a/grub-core/kern/i386/xen/startup_pvh.S
> +++ b/grub-core/kern/i386/xen/startup_pvh.S
> @@ -19,11 +19,61 @@
>
> #include <config.h>
> #include <grub/symbol.h>
> +#include <grub/machine/memory.h>
>
> .file "startup_pvh.S"
> .text
> + .globl start, _start
> + .code32
>
> +start:
> +_start:
> + cld
> + lgdt gdtdesc
> + ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
> +1:
> + movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
> + mov %eax, %ds
> + mov %eax, %es
> + mov %eax, %ss
Should not you load null descriptor into %fs and %gs?
Just in case...
> + leal LOCAL(stack_end), %esp
> +
> + /* Save address of start info structure. */
> + mov %ebx, pvh_start_info
> + call EXT_C(grub_main)
> + /* Doesn't return. */
> +
> + .p2align 3
> +gdt:
> + .word 0, 0
> + .byte 0, 0, 0, 0
> +
> + /* -- code segment --
> + * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
> + * type = 32bit code execute/read, DPL = 0
> + */
> + .word 0xFFFF, 0
> + .byte 0, 0x9A, 0xCF, 0
> +
> + /* -- data segment --
> + * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
> + * type = 32 bit data read/write, DPL = 0
> + */
> + .word 0xFFFF, 0
> + .byte 0, 0x92, 0xCF, 0
> +
> + .p2align 3
> +/* this is the GDT descriptor */
> +gdtdesc:
> + .word 0x17 /* limit */
> + .long gdt /* addr */
> +
> + .p2align 2
> /* Saved pointer to start info structure. */
> .globl pvh_start_info
> pvh_start_info:
> .long 0
> +
> + .bss
> + .space (1 << 22)
Hmmm... Why do we need 4 MiB here? If this is really needed then it begs for
a comment. And I would like to see a constant instead of plain number here.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 09/18] xen: add PVH boot entry code
2018-10-19 12:17 ` Daniel Kiper
(?)
@ 2018-10-19 14:50 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 14:50 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/2018 14:17, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:08PM +0200, Juergen Gross wrote:
>> Add the code for the Xen PVH mode boot entry.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
>> index e18ee5b31..0ddb63b31 100644
>> --- a/grub-core/kern/i386/xen/startup_pvh.S
>> +++ b/grub-core/kern/i386/xen/startup_pvh.S
>> @@ -19,11 +19,61 @@
>>
>> #include <config.h>
>> #include <grub/symbol.h>
>> +#include <grub/machine/memory.h>
>>
>> .file "startup_pvh.S"
>> .text
>> + .globl start, _start
>> + .code32
>>
>> +start:
>> +_start:
>> + cld
>> + lgdt gdtdesc
>> + ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
>> +1:
>> + movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
>> + mov %eax, %ds
>> + mov %eax, %es
>> + mov %eax, %ss
>
> Should not you load null descriptor into %fs and %gs?
> Just in case...
Hmm, if you want I can do that, sure.
>
>> + leal LOCAL(stack_end), %esp
>> +
>> + /* Save address of start info structure. */
>> + mov %ebx, pvh_start_info
>> + call EXT_C(grub_main)
>> + /* Doesn't return. */
>> +
>> + .p2align 3
>> +gdt:
>> + .word 0, 0
>> + .byte 0, 0, 0, 0
>> +
>> + /* -- code segment --
>> + * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
>> + * type = 32bit code execute/read, DPL = 0
>> + */
>> + .word 0xFFFF, 0
>> + .byte 0, 0x9A, 0xCF, 0
>> +
>> + /* -- data segment --
>> + * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
>> + * type = 32 bit data read/write, DPL = 0
>> + */
>> + .word 0xFFFF, 0
>> + .byte 0, 0x92, 0xCF, 0
>> +
>> + .p2align 3
>> +/* this is the GDT descriptor */
>> +gdtdesc:
>> + .word 0x17 /* limit */
>> + .long gdt /* addr */
>> +
>> + .p2align 2
>> /* Saved pointer to start info structure. */
>> .globl pvh_start_info
>> pvh_start_info:
>> .long 0
>> +
>> + .bss
>> + .space (1 << 22)
>
> Hmmm... Why do we need 4 MiB here? If this is really needed then it begs for
> a comment. And I would like to see a constant instead of plain number here.
This is just copied from xen/startup.S
I can reduce it to something near GRUB_MEMORY_MACHINE_PROT_STACK_SIZE
(about 64kB).
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 09/18] xen: add PVH boot entry code
2018-10-19 12:17 ` Daniel Kiper
(?)
(?)
@ 2018-10-19 14:50 ` Juergen Gross
2018-10-22 11:18 ` Daniel Kiper
2018-10-22 11:18 ` Daniel Kiper
-1 siblings, 2 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 14:50 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/2018 14:17, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:08PM +0200, Juergen Gross wrote:
>> Add the code for the Xen PVH mode boot entry.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
>> index e18ee5b31..0ddb63b31 100644
>> --- a/grub-core/kern/i386/xen/startup_pvh.S
>> +++ b/grub-core/kern/i386/xen/startup_pvh.S
>> @@ -19,11 +19,61 @@
>>
>> #include <config.h>
>> #include <grub/symbol.h>
>> +#include <grub/machine/memory.h>
>>
>> .file "startup_pvh.S"
>> .text
>> + .globl start, _start
>> + .code32
>>
>> +start:
>> +_start:
>> + cld
>> + lgdt gdtdesc
>> + ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
>> +1:
>> + movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
>> + mov %eax, %ds
>> + mov %eax, %es
>> + mov %eax, %ss
>
> Should not you load null descriptor into %fs and %gs?
> Just in case...
Hmm, if you want I can do that, sure.
>
>> + leal LOCAL(stack_end), %esp
>> +
>> + /* Save address of start info structure. */
>> + mov %ebx, pvh_start_info
>> + call EXT_C(grub_main)
>> + /* Doesn't return. */
>> +
>> + .p2align 3
>> +gdt:
>> + .word 0, 0
>> + .byte 0, 0, 0, 0
>> +
>> + /* -- code segment --
>> + * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
>> + * type = 32bit code execute/read, DPL = 0
>> + */
>> + .word 0xFFFF, 0
>> + .byte 0, 0x9A, 0xCF, 0
>> +
>> + /* -- data segment --
>> + * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
>> + * type = 32 bit data read/write, DPL = 0
>> + */
>> + .word 0xFFFF, 0
>> + .byte 0, 0x92, 0xCF, 0
>> +
>> + .p2align 3
>> +/* this is the GDT descriptor */
>> +gdtdesc:
>> + .word 0x17 /* limit */
>> + .long gdt /* addr */
>> +
>> + .p2align 2
>> /* Saved pointer to start info structure. */
>> .globl pvh_start_info
>> pvh_start_info:
>> .long 0
>> +
>> + .bss
>> + .space (1 << 22)
>
> Hmmm... Why do we need 4 MiB here? If this is really needed then it begs for
> a comment. And I would like to see a constant instead of plain number here.
This is just copied from xen/startup.S
I can reduce it to something near GRUB_MEMORY_MACHINE_PROT_STACK_SIZE
(about 64kB).
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 09/18] xen: add PVH boot entry code
2018-10-19 14:50 ` [Xen-devel] " Juergen Gross
@ 2018-10-22 11:18 ` Daniel Kiper
2018-10-22 11:18 ` Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:18 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Fri, Oct 19, 2018 at 04:50:25PM +0200, Juergen Gross wrote:
> On 19/10/2018 14:17, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:08PM +0200, Juergen Gross wrote:
> >> Add the code for the Xen PVH mode boot entry.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
> >> 1 file changed, 50 insertions(+)
> >>
> >> diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
> >> index e18ee5b31..0ddb63b31 100644
> >> --- a/grub-core/kern/i386/xen/startup_pvh.S
> >> +++ b/grub-core/kern/i386/xen/startup_pvh.S
> >> @@ -19,11 +19,61 @@
> >>
> >> #include <config.h>
> >> #include <grub/symbol.h>
> >> +#include <grub/machine/memory.h>
> >>
> >> .file "startup_pvh.S"
> >> .text
> >> + .globl start, _start
> >> + .code32
> >>
> >> +start:
> >> +_start:
> >> + cld
> >> + lgdt gdtdesc
> >> + ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
> >> +1:
> >> + movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
> >> + mov %eax, %ds
> >> + mov %eax, %es
> >> + mov %eax, %ss
> >
> > Should not you load null descriptor into %fs and %gs?
> > Just in case...
>
> Hmm, if you want I can do that, sure.
Please do.
> >> + leal LOCAL(stack_end), %esp
> >> +
> >> + /* Save address of start info structure. */
> >> + mov %ebx, pvh_start_info
> >> + call EXT_C(grub_main)
> >> + /* Doesn't return. */
> >> +
> >> + .p2align 3
> >> +gdt:
> >> + .word 0, 0
> >> + .byte 0, 0, 0, 0
> >> +
> >> + /* -- code segment --
> >> + * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
> >> + * type = 32bit code execute/read, DPL = 0
> >> + */
> >> + .word 0xFFFF, 0
> >> + .byte 0, 0x9A, 0xCF, 0
> >> +
> >> + /* -- data segment --
> >> + * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
> >> + * type = 32 bit data read/write, DPL = 0
> >> + */
> >> + .word 0xFFFF, 0
> >> + .byte 0, 0x92, 0xCF, 0
> >> +
> >> + .p2align 3
> >> +/* this is the GDT descriptor */
> >> +gdtdesc:
> >> + .word 0x17 /* limit */
> >> + .long gdt /* addr */
> >> +
> >> + .p2align 2
> >> /* Saved pointer to start info structure. */
> >> .globl pvh_start_info
> >> pvh_start_info:
> >> .long 0
> >> +
> >> + .bss
> >> + .space (1 << 22)
> >
> > Hmmm... Why do we need 4 MiB here? If this is really needed then it begs for
> > a comment. And I would like to see a constant instead of plain number here.
>
> This is just copied from xen/startup.S
>
> I can reduce it to something near GRUB_MEMORY_MACHINE_PROT_STACK_SIZE
> (about 64kB).
GRUB_MEMORY_MACHINE_PROT_STACK_SIZE works for me.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 09/18] xen: add PVH boot entry code
2018-10-19 14:50 ` [Xen-devel] " Juergen Gross
2018-10-22 11:18 ` Daniel Kiper
@ 2018-10-22 11:18 ` Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:18 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, xen-devel, phcoder
On Fri, Oct 19, 2018 at 04:50:25PM +0200, Juergen Gross wrote:
> On 19/10/2018 14:17, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:08PM +0200, Juergen Gross wrote:
> >> Add the code for the Xen PVH mode boot entry.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> grub-core/kern/i386/xen/startup_pvh.S | 50 +++++++++++++++++++++++++++++++++++
> >> 1 file changed, 50 insertions(+)
> >>
> >> diff --git a/grub-core/kern/i386/xen/startup_pvh.S b/grub-core/kern/i386/xen/startup_pvh.S
> >> index e18ee5b31..0ddb63b31 100644
> >> --- a/grub-core/kern/i386/xen/startup_pvh.S
> >> +++ b/grub-core/kern/i386/xen/startup_pvh.S
> >> @@ -19,11 +19,61 @@
> >>
> >> #include <config.h>
> >> #include <grub/symbol.h>
> >> +#include <grub/machine/memory.h>
> >>
> >> .file "startup_pvh.S"
> >> .text
> >> + .globl start, _start
> >> + .code32
> >>
> >> +start:
> >> +_start:
> >> + cld
> >> + lgdt gdtdesc
> >> + ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
> >> +1:
> >> + movl $GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
> >> + mov %eax, %ds
> >> + mov %eax, %es
> >> + mov %eax, %ss
> >
> > Should not you load null descriptor into %fs and %gs?
> > Just in case...
>
> Hmm, if you want I can do that, sure.
Please do.
> >> + leal LOCAL(stack_end), %esp
> >> +
> >> + /* Save address of start info structure. */
> >> + mov %ebx, pvh_start_info
> >> + call EXT_C(grub_main)
> >> + /* Doesn't return. */
> >> +
> >> + .p2align 3
> >> +gdt:
> >> + .word 0, 0
> >> + .byte 0, 0, 0, 0
> >> +
> >> + /* -- code segment --
> >> + * base = 0x00000000, limit = 0xFFFFF (4 KiB Granularity), present
> >> + * type = 32bit code execute/read, DPL = 0
> >> + */
> >> + .word 0xFFFF, 0
> >> + .byte 0, 0x9A, 0xCF, 0
> >> +
> >> + /* -- data segment --
> >> + * base = 0x00000000, limit 0xFFFFF (4 KiB Granularity), present
> >> + * type = 32 bit data read/write, DPL = 0
> >> + */
> >> + .word 0xFFFF, 0
> >> + .byte 0, 0x92, 0xCF, 0
> >> +
> >> + .p2align 3
> >> +/* this is the GDT descriptor */
> >> +gdtdesc:
> >> + .word 0x17 /* limit */
> >> + .long gdt /* addr */
> >> +
> >> + .p2align 2
> >> /* Saved pointer to start info structure. */
> >> .globl pvh_start_info
> >> pvh_start_info:
> >> .long 0
> >> +
> >> + .bss
> >> + .space (1 << 22)
> >
> > Hmmm... Why do we need 4 MiB here? If this is really needed then it begs for
> > a comment. And I would like to see a constant instead of plain number here.
>
> This is just copied from xen/startup.S
>
> I can reduce it to something near GRUB_MEMORY_MACHINE_PROT_STACK_SIZE
> (about 64kB).
GRUB_MEMORY_MACHINE_PROT_STACK_SIZE works for me.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Add the needed code to setup the hypercall page for calling into the
Xen hypervisor.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index 182ef95f9..c1b1cf8db 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -20,14 +20,84 @@
#include <grub/misc.h>
#include <grub/memory.h>
#include <grub/mm.h>
+#include <grub/i386/cpuid.h>
#include <grub/xen.h>
#include <grub/machine/kernel.h>
grub_uint64_t grub_rsdp_addr;
+static struct { char _entry[32]; } hypercall_page[128]
+ __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
+
+static grub_uint32_t xen_cpuid_base;
+
+static void
+grub_xen_early_halt (void)
+{
+ asm volatile ("hlt");
+}
+
+static void
+grub_xen_cpuid_base (void)
+{
+ grub_uint32_t base, eax, signature[3];
+
+ for (base = 0x40000000; base < 0x40010000; base += 0x100)
+ {
+ grub_cpuid (base, eax, signature[0], signature[1], signature[2]);
+ if (!grub_memcmp ("XenVMMXenVMM", signature, 12) && (eax - base) >= 2)
+ {
+ xen_cpuid_base = base;
+ return;
+ }
+ }
+
+ grub_xen_early_halt ();
+}
+
+static void
+grub_xen_setup_hypercall_page (void)
+{
+ grub_uint32_t msr, pfn, eax, ebx, ecx, edx;
+
+ grub_cpuid (xen_cpuid_base + 2, eax, ebx, ecx, edx);
+ msr = ebx;
+ pfn = (grub_uint32_t) (&hypercall_page[0]);
+
+ asm volatile ("wrmsr" : : "c" (msr), "a" (pfn), "d" (0) : "memory");
+}
+
+int
+grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
+ grub_uint32_t a1, grub_uint32_t a2,
+ grub_uint32_t a3, grub_uint32_t a4,
+ grub_uint32_t a5 __attribute__ ((unused)))
+{
+ register unsigned long __res asm("eax");
+ register unsigned long __arg0 asm("ebx") = __arg0;
+ register unsigned long __arg1 asm("ecx") = __arg1;
+ register unsigned long __arg2 asm("edx") = __arg2;
+ register unsigned long __arg3 asm("esi") = __arg3;
+ register unsigned long __arg4 asm("edi") = __arg4;
+
+ __arg0 = a0;
+ __arg1 = a1;
+ __arg2 = a2;
+ __arg3 = a3;
+ __arg4 = a4;
+ asm volatile ("call *%[callno]"
+ : "=r" (__res), "+r" (__arg0), "+r" (__arg1), "+r" (__arg2),
+ "+r" (__arg3), "+r" (__arg4)
+ : [callno] "a" (&hypercall_page[callno])
+ : "memory");
+ return __res;
+}
+
void
grub_xen_setup_pvh (void)
{
+ grub_xen_cpuid_base ();
+ grub_xen_setup_hypercall_page ();
}
grub_err_t
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 10/18] xen: setup hypercall page for PVH
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Add the needed code to setup the hypercall page for calling into the
Xen hypervisor.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index 182ef95f9..c1b1cf8db 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -20,14 +20,84 @@
#include <grub/misc.h>
#include <grub/memory.h>
#include <grub/mm.h>
+#include <grub/i386/cpuid.h>
#include <grub/xen.h>
#include <grub/machine/kernel.h>
grub_uint64_t grub_rsdp_addr;
+static struct { char _entry[32]; } hypercall_page[128]
+ __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
+
+static grub_uint32_t xen_cpuid_base;
+
+static void
+grub_xen_early_halt (void)
+{
+ asm volatile ("hlt");
+}
+
+static void
+grub_xen_cpuid_base (void)
+{
+ grub_uint32_t base, eax, signature[3];
+
+ for (base = 0x40000000; base < 0x40010000; base += 0x100)
+ {
+ grub_cpuid (base, eax, signature[0], signature[1], signature[2]);
+ if (!grub_memcmp ("XenVMMXenVMM", signature, 12) && (eax - base) >= 2)
+ {
+ xen_cpuid_base = base;
+ return;
+ }
+ }
+
+ grub_xen_early_halt ();
+}
+
+static void
+grub_xen_setup_hypercall_page (void)
+{
+ grub_uint32_t msr, pfn, eax, ebx, ecx, edx;
+
+ grub_cpuid (xen_cpuid_base + 2, eax, ebx, ecx, edx);
+ msr = ebx;
+ pfn = (grub_uint32_t) (&hypercall_page[0]);
+
+ asm volatile ("wrmsr" : : "c" (msr), "a" (pfn), "d" (0) : "memory");
+}
+
+int
+grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
+ grub_uint32_t a1, grub_uint32_t a2,
+ grub_uint32_t a3, grub_uint32_t a4,
+ grub_uint32_t a5 __attribute__ ((unused)))
+{
+ register unsigned long __res asm("eax");
+ register unsigned long __arg0 asm("ebx") = __arg0;
+ register unsigned long __arg1 asm("ecx") = __arg1;
+ register unsigned long __arg2 asm("edx") = __arg2;
+ register unsigned long __arg3 asm("esi") = __arg3;
+ register unsigned long __arg4 asm("edi") = __arg4;
+
+ __arg0 = a0;
+ __arg1 = a1;
+ __arg2 = a2;
+ __arg3 = a3;
+ __arg4 = a4;
+ asm volatile ("call *%[callno]"
+ : "=r" (__res), "+r" (__arg0), "+r" (__arg1), "+r" (__arg2),
+ "+r" (__arg3), "+r" (__arg4)
+ : [callno] "a" (&hypercall_page[callno])
+ : "memory");
+ return __res;
+}
+
void
grub_xen_setup_pvh (void)
{
+ grub_xen_cpuid_base ();
+ grub_xen_setup_hypercall_page ();
}
grub_err_t
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-09 11:03 ` Juergen Gross
@ 2018-10-19 12:30 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:30 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
> Add the needed code to setup the hypercall page for calling into the
> Xen hypervisor.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index 182ef95f9..c1b1cf8db 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -20,14 +20,84 @@
> #include <grub/misc.h>
> #include <grub/memory.h>
> #include <grub/mm.h>
> +#include <grub/i386/cpuid.h>
> #include <grub/xen.h>
> #include <grub/machine/kernel.h>
>
> grub_uint64_t grub_rsdp_addr;
>
> +static struct { char _entry[32]; } hypercall_page[128]
> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> +
> +static grub_uint32_t xen_cpuid_base;
> +
> +static void
> +grub_xen_early_halt (void)
> +{
> + asm volatile ("hlt");
> +}
> +
> +static void
> +grub_xen_cpuid_base (void)
> +{
> + grub_uint32_t base, eax, signature[3];
> +
> + for (base = 0x40000000; base < 0x40010000; base += 0x100)
> + {
> + grub_cpuid (base, eax, signature[0], signature[1], signature[2]);
> + if (!grub_memcmp ("XenVMMXenVMM", signature, 12) && (eax - base) >= 2)
> + {
> + xen_cpuid_base = base;
> + return;
> + }
> + }
> +
> + grub_xen_early_halt ();
> +}
> +
> +static void
> +grub_xen_setup_hypercall_page (void)
> +{
> + grub_uint32_t msr, pfn, eax, ebx, ecx, edx;
> +
> + grub_cpuid (xen_cpuid_base + 2, eax, ebx, ecx, edx);
> + msr = ebx;
> + pfn = (grub_uint32_t) (&hypercall_page[0]);
> +
> + asm volatile ("wrmsr" : : "c" (msr), "a" (pfn), "d" (0) : "memory");
> +}
> +
> +int
> +grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> + grub_uint32_t a1, grub_uint32_t a2,
> + grub_uint32_t a3, grub_uint32_t a4,
> + grub_uint32_t a5 __attribute__ ((unused)))
> +{
> + register unsigned long __res asm("eax");
> + register unsigned long __arg0 asm("ebx") = __arg0;
> + register unsigned long __arg1 asm("ecx") = __arg1;
> + register unsigned long __arg2 asm("edx") = __arg2;
> + register unsigned long __arg3 asm("esi") = __arg3;
> + register unsigned long __arg4 asm("edi") = __arg4;
Why do we need this play with registers. Does not asm below
work with "a", "b", ... like above?
> +
> + __arg0 = a0;
> + __arg1 = a1;
> + __arg2 = a2;
> + __arg3 = a3;
> + __arg4 = a4;
> + asm volatile ("call *%[callno]"
> + : "=r" (__res), "+r" (__arg0), "+r" (__arg1), "+r" (__arg2),
> + "+r" (__arg3), "+r" (__arg4)
> + : [callno] "a" (&hypercall_page[callno])
> + : "memory");
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 10/18] xen: setup hypercall page for PVH
@ 2018-10-19 12:30 ` Daniel Kiper
0 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:30 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
> Add the needed code to setup the hypercall page for calling into the
> Xen hypervisor.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index 182ef95f9..c1b1cf8db 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -20,14 +20,84 @@
> #include <grub/misc.h>
> #include <grub/memory.h>
> #include <grub/mm.h>
> +#include <grub/i386/cpuid.h>
> #include <grub/xen.h>
> #include <grub/machine/kernel.h>
>
> grub_uint64_t grub_rsdp_addr;
>
> +static struct { char _entry[32]; } hypercall_page[128]
> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> +
> +static grub_uint32_t xen_cpuid_base;
> +
> +static void
> +grub_xen_early_halt (void)
> +{
> + asm volatile ("hlt");
> +}
> +
> +static void
> +grub_xen_cpuid_base (void)
> +{
> + grub_uint32_t base, eax, signature[3];
> +
> + for (base = 0x40000000; base < 0x40010000; base += 0x100)
> + {
> + grub_cpuid (base, eax, signature[0], signature[1], signature[2]);
> + if (!grub_memcmp ("XenVMMXenVMM", signature, 12) && (eax - base) >= 2)
> + {
> + xen_cpuid_base = base;
> + return;
> + }
> + }
> +
> + grub_xen_early_halt ();
> +}
> +
> +static void
> +grub_xen_setup_hypercall_page (void)
> +{
> + grub_uint32_t msr, pfn, eax, ebx, ecx, edx;
> +
> + grub_cpuid (xen_cpuid_base + 2, eax, ebx, ecx, edx);
> + msr = ebx;
> + pfn = (grub_uint32_t) (&hypercall_page[0]);
> +
> + asm volatile ("wrmsr" : : "c" (msr), "a" (pfn), "d" (0) : "memory");
> +}
> +
> +int
> +grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> + grub_uint32_t a1, grub_uint32_t a2,
> + grub_uint32_t a3, grub_uint32_t a4,
> + grub_uint32_t a5 __attribute__ ((unused)))
> +{
> + register unsigned long __res asm("eax");
> + register unsigned long __arg0 asm("ebx") = __arg0;
> + register unsigned long __arg1 asm("ecx") = __arg1;
> + register unsigned long __arg2 asm("edx") = __arg2;
> + register unsigned long __arg3 asm("esi") = __arg3;
> + register unsigned long __arg4 asm("edi") = __arg4;
Why do we need this play with registers. Does not asm below
work with "a", "b", ... like above?
> +
> + __arg0 = a0;
> + __arg1 = a1;
> + __arg2 = a2;
> + __arg3 = a3;
> + __arg4 = a4;
> + asm volatile ("call *%[callno]"
> + : "=r" (__res), "+r" (__arg0), "+r" (__arg1), "+r" (__arg2),
> + "+r" (__arg3), "+r" (__arg4)
> + : [callno] "a" (&hypercall_page[callno])
> + : "memory");
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-19 12:30 ` Daniel Kiper
(?)
@ 2018-10-19 12:48 ` Andrew Cooper
-1 siblings, 0 replies; 148+ messages in thread
From: Andrew Cooper @ 2018-10-19 12:48 UTC (permalink / raw)
To: Daniel Kiper, Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/18 13:30, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
>> +
>> + __arg0 = a0;
>> + __arg1 = a1;
>> + __arg2 = a2;
>> + __arg3 = a3;
>> + __arg4 = a4;
>> + asm volatile ("call *%[callno]"
>> + : "=r" (__res), "+r" (__arg0), "+r" (__arg1), "+r" (__arg2),
>> + "+r" (__arg3), "+r" (__arg4)
>> + : [callno] "a" (&hypercall_page[callno])
>> + : "memory");
call hypercall_page + %c[offset]
passing [offset] "i" (callno * 32)
which gives you a direct call, rather than an indirect one.
~Andrew
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-19 12:30 ` Daniel Kiper
(?)
(?)
@ 2018-10-19 12:48 ` Andrew Cooper
-1 siblings, 0 replies; 148+ messages in thread
From: Andrew Cooper @ 2018-10-19 12:48 UTC (permalink / raw)
To: Daniel Kiper, Juergen Gross; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/18 13:30, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
>> +
>> + __arg0 = a0;
>> + __arg1 = a1;
>> + __arg2 = a2;
>> + __arg3 = a3;
>> + __arg4 = a4;
>> + asm volatile ("call *%[callno]"
>> + : "=r" (__res), "+r" (__arg0), "+r" (__arg1), "+r" (__arg2),
>> + "+r" (__arg3), "+r" (__arg4)
>> + : [callno] "a" (&hypercall_page[callno])
>> + : "memory");
call hypercall_page + %c[offset]
passing [offset] "i" (callno * 32)
which gives you a direct call, rather than an indirect one.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-19 12:30 ` Daniel Kiper
` (2 preceding siblings ...)
(?)
@ 2018-10-19 15:01 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:01 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/2018 14:30, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
>> Add the needed code to setup the hypercall page for calling into the
>> Xen hypervisor.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index 182ef95f9..c1b1cf8db 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -20,14 +20,84 @@
>> #include <grub/misc.h>
>> #include <grub/memory.h>
>> #include <grub/mm.h>
>> +#include <grub/i386/cpuid.h>
>> #include <grub/xen.h>
>> #include <grub/machine/kernel.h>
>>
>> grub_uint64_t grub_rsdp_addr;
>>
>> +static struct { char _entry[32]; } hypercall_page[128]
>> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>> +
>> +static grub_uint32_t xen_cpuid_base;
>> +
>> +static void
>> +grub_xen_early_halt (void)
>> +{
>> + asm volatile ("hlt");
>> +}
>> +
>> +static void
>> +grub_xen_cpuid_base (void)
>> +{
>> + grub_uint32_t base, eax, signature[3];
>> +
>> + for (base = 0x40000000; base < 0x40010000; base += 0x100)
>> + {
>> + grub_cpuid (base, eax, signature[0], signature[1], signature[2]);
>> + if (!grub_memcmp ("XenVMMXenVMM", signature, 12) && (eax - base) >= 2)
>> + {
>> + xen_cpuid_base = base;
>> + return;
>> + }
>> + }
>> +
>> + grub_xen_early_halt ();
>> +}
>> +
>> +static void
>> +grub_xen_setup_hypercall_page (void)
>> +{
>> + grub_uint32_t msr, pfn, eax, ebx, ecx, edx;
>> +
>> + grub_cpuid (xen_cpuid_base + 2, eax, ebx, ecx, edx);
>> + msr = ebx;
>> + pfn = (grub_uint32_t) (&hypercall_page[0]);
>> +
>> + asm volatile ("wrmsr" : : "c" (msr), "a" (pfn), "d" (0) : "memory");
>> +}
>> +
>> +int
>> +grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> + grub_uint32_t a1, grub_uint32_t a2,
>> + grub_uint32_t a3, grub_uint32_t a4,
>> + grub_uint32_t a5 __attribute__ ((unused)))
>> +{
>> + register unsigned long __res asm("eax");
>> + register unsigned long __arg0 asm("ebx") = __arg0;
>> + register unsigned long __arg1 asm("ecx") = __arg1;
>> + register unsigned long __arg2 asm("edx") = __arg2;
>> + register unsigned long __arg3 asm("esi") = __arg3;
>> + register unsigned long __arg4 asm("edi") = __arg4;
>
> Why do we need this play with registers. Does not asm below
> work with "a", "b", ... like above?
Probably, yes. This was inspired by Linux 32-bit version.
I can use the mini-os variant which combines Andrew's suggestion
and yours.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-19 12:30 ` Daniel Kiper
` (3 preceding siblings ...)
(?)
@ 2018-10-19 15:01 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:01 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/2018 14:30, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
>> Add the needed code to setup the hypercall page for calling into the
>> Xen hypervisor.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index 182ef95f9..c1b1cf8db 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -20,14 +20,84 @@
>> #include <grub/misc.h>
>> #include <grub/memory.h>
>> #include <grub/mm.h>
>> +#include <grub/i386/cpuid.h>
>> #include <grub/xen.h>
>> #include <grub/machine/kernel.h>
>>
>> grub_uint64_t grub_rsdp_addr;
>>
>> +static struct { char _entry[32]; } hypercall_page[128]
>> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>> +
>> +static grub_uint32_t xen_cpuid_base;
>> +
>> +static void
>> +grub_xen_early_halt (void)
>> +{
>> + asm volatile ("hlt");
>> +}
>> +
>> +static void
>> +grub_xen_cpuid_base (void)
>> +{
>> + grub_uint32_t base, eax, signature[3];
>> +
>> + for (base = 0x40000000; base < 0x40010000; base += 0x100)
>> + {
>> + grub_cpuid (base, eax, signature[0], signature[1], signature[2]);
>> + if (!grub_memcmp ("XenVMMXenVMM", signature, 12) && (eax - base) >= 2)
>> + {
>> + xen_cpuid_base = base;
>> + return;
>> + }
>> + }
>> +
>> + grub_xen_early_halt ();
>> +}
>> +
>> +static void
>> +grub_xen_setup_hypercall_page (void)
>> +{
>> + grub_uint32_t msr, pfn, eax, ebx, ecx, edx;
>> +
>> + grub_cpuid (xen_cpuid_base + 2, eax, ebx, ecx, edx);
>> + msr = ebx;
>> + pfn = (grub_uint32_t) (&hypercall_page[0]);
>> +
>> + asm volatile ("wrmsr" : : "c" (msr), "a" (pfn), "d" (0) : "memory");
>> +}
>> +
>> +int
>> +grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> + grub_uint32_t a1, grub_uint32_t a2,
>> + grub_uint32_t a3, grub_uint32_t a4,
>> + grub_uint32_t a5 __attribute__ ((unused)))
>> +{
>> + register unsigned long __res asm("eax");
>> + register unsigned long __arg0 asm("ebx") = __arg0;
>> + register unsigned long __arg1 asm("ecx") = __arg1;
>> + register unsigned long __arg2 asm("edx") = __arg2;
>> + register unsigned long __arg3 asm("esi") = __arg3;
>> + register unsigned long __arg4 asm("edi") = __arg4;
>
> Why do we need this play with registers. Does not asm below
> work with "a", "b", ... like above?
Probably, yes. This was inspired by Linux 32-bit version.
I can use the mini-os variant which combines Andrew's suggestion
and yours.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-19 15:40 ` Roger Pau Monné
-1 siblings, 0 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 15:40 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
> Add the needed code to setup the hypercall page for calling into the
> Xen hypervisor.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index 182ef95f9..c1b1cf8db 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -20,14 +20,84 @@
> #include <grub/misc.h>
> #include <grub/memory.h>
> #include <grub/mm.h>
> +#include <grub/i386/cpuid.h>
> #include <grub/xen.h>
> #include <grub/machine/kernel.h>
>
> grub_uint64_t grub_rsdp_addr;
>
> +static struct { char _entry[32]; } hypercall_page[128]
> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> +
> +static grub_uint32_t xen_cpuid_base;
> +
> +static void
> +grub_xen_early_halt (void)
I would rename this to grub_xen_early_crash
> +{
And you can use the 0xe9 IO port to print a crash debug message even
before initializing the hypercall page, I think this would be helpful
here.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-09 11:03 ` Juergen Gross
` (2 preceding siblings ...)
(?)
@ 2018-10-19 15:40 ` Roger Pau Monné
2018-10-19 15:59 ` [Xen-devel] " Juergen Gross
-1 siblings, 1 reply; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 15:40 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
> Add the needed code to setup the hypercall page for calling into the
> Xen hypervisor.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index 182ef95f9..c1b1cf8db 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -20,14 +20,84 @@
> #include <grub/misc.h>
> #include <grub/memory.h>
> #include <grub/mm.h>
> +#include <grub/i386/cpuid.h>
> #include <grub/xen.h>
> #include <grub/machine/kernel.h>
>
> grub_uint64_t grub_rsdp_addr;
>
> +static struct { char _entry[32]; } hypercall_page[128]
> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> +
> +static grub_uint32_t xen_cpuid_base;
> +
> +static void
> +grub_xen_early_halt (void)
I would rename this to grub_xen_early_crash
> +{
And you can use the 0xe9 IO port to print a crash debug message even
before initializing the hypercall page, I think this would be helpful
here.
Roger.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 10/18] xen: setup hypercall page for PVH
2018-10-19 15:40 ` [Xen-devel] " Roger Pau Monné
@ 2018-10-19 15:59 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:59 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On 19/10/2018 17:40, Roger Pau Monné wrote:
> On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
>> Add the needed code to setup the hypercall page for calling into the
>> Xen hypervisor.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index 182ef95f9..c1b1cf8db 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -20,14 +20,84 @@
>> #include <grub/misc.h>
>> #include <grub/memory.h>
>> #include <grub/mm.h>
>> +#include <grub/i386/cpuid.h>
>> #include <grub/xen.h>
>> #include <grub/machine/kernel.h>
>>
>> grub_uint64_t grub_rsdp_addr;
>>
>> +static struct { char _entry[32]; } hypercall_page[128]
>> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>> +
>> +static grub_uint32_t xen_cpuid_base;
>> +
>> +static void
>> +grub_xen_early_halt (void)
>
> I would rename this to grub_xen_early_crash
>
>> +{
>
> And you can use the 0xe9 IO port to print a crash debug message even
> before initializing the hypercall page, I think this would be helpful
> here.
Aah, I didn't know that.
Thanks, I'll change grub_xen_early_halt() to grub_xen_panic() taking a
string as parameter.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 10/18] xen: setup hypercall page for PVH
@ 2018-10-19 15:59 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:59 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On 19/10/2018 17:40, Roger Pau Monné wrote:
> On Tue, Oct 09, 2018 at 01:03:09PM +0200, Juergen Gross wrote:
>> Add the needed code to setup the hypercall page for calling into the
>> Xen hypervisor.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 70 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index 182ef95f9..c1b1cf8db 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -20,14 +20,84 @@
>> #include <grub/misc.h>
>> #include <grub/memory.h>
>> #include <grub/mm.h>
>> +#include <grub/i386/cpuid.h>
>> #include <grub/xen.h>
>> #include <grub/machine/kernel.h>
>>
>> grub_uint64_t grub_rsdp_addr;
>>
>> +static struct { char _entry[32]; } hypercall_page[128]
>> + __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>> +
>> +static grub_uint32_t xen_cpuid_base;
>> +
>> +static void
>> +grub_xen_early_halt (void)
>
> I would rename this to grub_xen_early_crash
>
>> +{
>
> And you can use the 0xe9 IO port to print a crash debug message even
> before initializing the hypercall page, I think this would be helpful
> here.
Aah, I didn't know that.
Thanks, I'll change grub_xen_early_halt() to grub_xen_panic() taking a
string as parameter.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 11/18] xen: get memory map from hypervisor for PVH
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Retrieve the memory map from the hypervisor and normalize it to contain
no overlapping entries and to be sorted by address.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 98 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index c1b1cf8db..b4933b454 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -22,7 +22,16 @@
#include <grub/mm.h>
#include <grub/i386/cpuid.h>
#include <grub/xen.h>
+#include <grub/i386/linux.h>
#include <grub/machine/kernel.h>
+#include <xen/memory.h>
+
+struct xen_machine_mmap_entry
+{
+ grub_uint64_t addr;
+ grub_uint64_t len;
+ grub_uint32_t type;
+} GRUB_PACKED;
grub_uint64_t grub_rsdp_addr;
@@ -30,6 +39,8 @@ static struct { char _entry[32]; } hypercall_page[128]
__attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
static grub_uint32_t xen_cpuid_base;
+static struct xen_machine_mmap_entry map[128];
+static unsigned int nr_map_entries;
static void
grub_xen_early_halt (void)
@@ -93,11 +104,98 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
return __res;
}
+static void
+grub_xen_sort_mmap (void)
+{
+ grub_uint64_t from, to;
+ unsigned int i;
+ struct xen_machine_mmap_entry tmp;
+
+ /* Align map entries to page boundaries. */
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ from = map[i].addr;
+ to = from + map[i].len;
+ if (map[i].type == GRUB_MEMORY_AVAILABLE)
+ {
+ from = ALIGN_UP(from, GRUB_XEN_PAGE_SIZE);
+ to = ALIGN_DOWN(to, GRUB_XEN_PAGE_SIZE);
+ }
+ else
+ {
+ from = ALIGN_DOWN(from, GRUB_XEN_PAGE_SIZE);
+ to = ALIGN_UP(to, GRUB_XEN_PAGE_SIZE);
+ }
+ map[i].addr = from;
+ map[i].len = to - from;
+ }
+
+ again:
+ /* Sort entries by start address. */
+ for (i = 1; i < nr_map_entries; i++)
+ {
+ if (map[i].addr >= map[i - 1].addr)
+ continue;
+ tmp = map[i];
+ map[i] = map[i - 1];
+ map[i - 1] = tmp;
+ i = 0;
+ }
+
+ /* Detect overlapping areas. */
+ for (i = 1; i < nr_map_entries; i++)
+ {
+ if (map[i].addr >= map[i - 1].addr + map[i - 1].len)
+ continue;
+ tmp = map[i - 1];
+ map[i - 1].len = map[i].addr - map[i - 1].addr;
+ if (map[i].addr + map[i].len >= tmp.addr + tmp.len)
+ continue;
+ if (nr_map_entries < ARRAY_SIZE(map))
+ {
+ map[nr_map_entries].addr = map[i].addr + map[i].len;
+ map[nr_map_entries].len = tmp.addr + tmp.len - map[nr_map_entries].addr;
+ map[nr_map_entries].type = tmp.type;
+ nr_map_entries++;
+ goto again;
+ }
+ }
+
+ /* Merge adjacent entries. */
+ for (i = 1; i < nr_map_entries; i++)
+ {
+ if (map[i].type == map[i - 1].type &&
+ map[i].addr == map[i - 1].addr + map[i - 1].len)
+ {
+ map[i - 1].len += map[i].len;
+ map[i] = map[nr_map_entries - 1];
+ nr_map_entries--;
+ goto again;
+ }
+ }
+}
+
+static void
+grub_xen_get_mmap (void)
+{
+ struct xen_memory_map memmap;
+
+ memmap.nr_entries = ARRAY_SIZE(map);
+ set_xen_guest_handle (memmap.buffer, map);
+ if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_memory_map,
+ (grub_uint32_t) (&memmap), 0, 0, 0, 0))
+ grub_xen_early_halt ();
+ nr_map_entries = memmap.nr_entries;
+
+ grub_xen_sort_mmap ();
+}
+
void
grub_xen_setup_pvh (void)
{
grub_xen_cpuid_base ();
grub_xen_setup_hypercall_page ();
+ grub_xen_get_mmap ();
}
grub_err_t
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 11/18] xen: get memory map from hypervisor for PVH
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Retrieve the memory map from the hypervisor and normalize it to contain
no overlapping entries and to be sorted by address.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 98 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index c1b1cf8db..b4933b454 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -22,7 +22,16 @@
#include <grub/mm.h>
#include <grub/i386/cpuid.h>
#include <grub/xen.h>
+#include <grub/i386/linux.h>
#include <grub/machine/kernel.h>
+#include <xen/memory.h>
+
+struct xen_machine_mmap_entry
+{
+ grub_uint64_t addr;
+ grub_uint64_t len;
+ grub_uint32_t type;
+} GRUB_PACKED;
grub_uint64_t grub_rsdp_addr;
@@ -30,6 +39,8 @@ static struct { char _entry[32]; } hypercall_page[128]
__attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
static grub_uint32_t xen_cpuid_base;
+static struct xen_machine_mmap_entry map[128];
+static unsigned int nr_map_entries;
static void
grub_xen_early_halt (void)
@@ -93,11 +104,98 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
return __res;
}
+static void
+grub_xen_sort_mmap (void)
+{
+ grub_uint64_t from, to;
+ unsigned int i;
+ struct xen_machine_mmap_entry tmp;
+
+ /* Align map entries to page boundaries. */
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ from = map[i].addr;
+ to = from + map[i].len;
+ if (map[i].type == GRUB_MEMORY_AVAILABLE)
+ {
+ from = ALIGN_UP(from, GRUB_XEN_PAGE_SIZE);
+ to = ALIGN_DOWN(to, GRUB_XEN_PAGE_SIZE);
+ }
+ else
+ {
+ from = ALIGN_DOWN(from, GRUB_XEN_PAGE_SIZE);
+ to = ALIGN_UP(to, GRUB_XEN_PAGE_SIZE);
+ }
+ map[i].addr = from;
+ map[i].len = to - from;
+ }
+
+ again:
+ /* Sort entries by start address. */
+ for (i = 1; i < nr_map_entries; i++)
+ {
+ if (map[i].addr >= map[i - 1].addr)
+ continue;
+ tmp = map[i];
+ map[i] = map[i - 1];
+ map[i - 1] = tmp;
+ i = 0;
+ }
+
+ /* Detect overlapping areas. */
+ for (i = 1; i < nr_map_entries; i++)
+ {
+ if (map[i].addr >= map[i - 1].addr + map[i - 1].len)
+ continue;
+ tmp = map[i - 1];
+ map[i - 1].len = map[i].addr - map[i - 1].addr;
+ if (map[i].addr + map[i].len >= tmp.addr + tmp.len)
+ continue;
+ if (nr_map_entries < ARRAY_SIZE(map))
+ {
+ map[nr_map_entries].addr = map[i].addr + map[i].len;
+ map[nr_map_entries].len = tmp.addr + tmp.len - map[nr_map_entries].addr;
+ map[nr_map_entries].type = tmp.type;
+ nr_map_entries++;
+ goto again;
+ }
+ }
+
+ /* Merge adjacent entries. */
+ for (i = 1; i < nr_map_entries; i++)
+ {
+ if (map[i].type == map[i - 1].type &&
+ map[i].addr == map[i - 1].addr + map[i - 1].len)
+ {
+ map[i - 1].len += map[i].len;
+ map[i] = map[nr_map_entries - 1];
+ nr_map_entries--;
+ goto again;
+ }
+ }
+}
+
+static void
+grub_xen_get_mmap (void)
+{
+ struct xen_memory_map memmap;
+
+ memmap.nr_entries = ARRAY_SIZE(map);
+ set_xen_guest_handle (memmap.buffer, map);
+ if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_memory_map,
+ (grub_uint32_t) (&memmap), 0, 0, 0, 0))
+ grub_xen_early_halt ();
+ nr_map_entries = memmap.nr_entries;
+
+ grub_xen_sort_mmap ();
+}
+
void
grub_xen_setup_pvh (void)
{
grub_xen_cpuid_base ();
grub_xen_setup_hypercall_page ();
+ grub_xen_get_mmap ();
}
grub_err_t
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 11/18] xen: get memory map from hypervisor for PVH
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-19 12:40 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:40 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:10PM +0200, Juergen Gross wrote:
> Retrieve the memory map from the hypervisor and normalize it to contain
> no overlapping entries and to be sorted by address.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 98 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index c1b1cf8db..b4933b454 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -22,7 +22,16 @@
> #include <grub/mm.h>
> #include <grub/i386/cpuid.h>
> #include <grub/xen.h>
> +#include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/memory.h>
> +
> +struct xen_machine_mmap_entry
> +{
> + grub_uint64_t addr;
> + grub_uint64_t len;
> + grub_uint32_t type;
> +} GRUB_PACKED;
Could not we reuse grub_e820_mmap_entry here?
> grub_uint64_t grub_rsdp_addr;
>
> @@ -30,6 +39,8 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct xen_machine_mmap_entry map[128];
A constant instead of 128? If no why 128?
> +static unsigned int nr_map_entries;
>
> static void
> grub_xen_early_halt (void)
> @@ -93,11 +104,98 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static void
> +grub_xen_sort_mmap (void)
> +{
> + grub_uint64_t from, to;
> + unsigned int i;
> + struct xen_machine_mmap_entry tmp;
> +
> + /* Align map entries to page boundaries. */
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + from = map[i].addr;
> + to = from + map[i].len;
> + if (map[i].type == GRUB_MEMORY_AVAILABLE)
> + {
> + from = ALIGN_UP(from, GRUB_XEN_PAGE_SIZE);
Lack of space between macro name and "(".
Here and below...
> + to = ALIGN_DOWN(to, GRUB_XEN_PAGE_SIZE);
> + }
> + else
> + {
> + from = ALIGN_DOWN(from, GRUB_XEN_PAGE_SIZE);
> + to = ALIGN_UP(to, GRUB_XEN_PAGE_SIZE);
> + }
> + map[i].addr = from;
> + map[i].len = to - from;
> + }
[...]
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 11/18] xen: get memory map from hypervisor for PVH
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-19 12:40 ` Daniel Kiper
2018-10-19 15:06 ` Juergen Gross
2018-10-19 15:06 ` [Xen-devel] " Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:40 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:10PM +0200, Juergen Gross wrote:
> Retrieve the memory map from the hypervisor and normalize it to contain
> no overlapping entries and to be sorted by address.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 98 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index c1b1cf8db..b4933b454 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -22,7 +22,16 @@
> #include <grub/mm.h>
> #include <grub/i386/cpuid.h>
> #include <grub/xen.h>
> +#include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/memory.h>
> +
> +struct xen_machine_mmap_entry
> +{
> + grub_uint64_t addr;
> + grub_uint64_t len;
> + grub_uint32_t type;
> +} GRUB_PACKED;
Could not we reuse grub_e820_mmap_entry here?
> grub_uint64_t grub_rsdp_addr;
>
> @@ -30,6 +39,8 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct xen_machine_mmap_entry map[128];
A constant instead of 128? If no why 128?
> +static unsigned int nr_map_entries;
>
> static void
> grub_xen_early_halt (void)
> @@ -93,11 +104,98 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static void
> +grub_xen_sort_mmap (void)
> +{
> + grub_uint64_t from, to;
> + unsigned int i;
> + struct xen_machine_mmap_entry tmp;
> +
> + /* Align map entries to page boundaries. */
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + from = map[i].addr;
> + to = from + map[i].len;
> + if (map[i].type == GRUB_MEMORY_AVAILABLE)
> + {
> + from = ALIGN_UP(from, GRUB_XEN_PAGE_SIZE);
Lack of space between macro name and "(".
Here and below...
> + to = ALIGN_DOWN(to, GRUB_XEN_PAGE_SIZE);
> + }
> + else
> + {
> + from = ALIGN_DOWN(from, GRUB_XEN_PAGE_SIZE);
> + to = ALIGN_UP(to, GRUB_XEN_PAGE_SIZE);
> + }
> + map[i].addr = from;
> + map[i].len = to - from;
> + }
[...]
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 11/18] xen: get memory map from hypervisor for PVH
2018-10-19 12:40 ` Daniel Kiper
@ 2018-10-19 15:06 ` Juergen Gross
2018-10-19 15:06 ` [Xen-devel] " Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:06 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/2018 14:40, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:10PM +0200, Juergen Gross wrote:
>> Retrieve the memory map from the hypervisor and normalize it to contain
>> no overlapping entries and to be sorted by address.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 98 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 98 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index c1b1cf8db..b4933b454 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -22,7 +22,16 @@
>> #include <grub/mm.h>
>> #include <grub/i386/cpuid.h>
>> #include <grub/xen.h>
>> +#include <grub/i386/linux.h>
>> #include <grub/machine/kernel.h>
>> +#include <xen/memory.h>
>> +
>> +struct xen_machine_mmap_entry
>> +{
>> + grub_uint64_t addr;
>> + grub_uint64_t len;
>> + grub_uint32_t type;
>> +} GRUB_PACKED;
>
> Could not we reuse grub_e820_mmap_entry here?
This is defined only locally in grub-core/mmap/i386/pc/mmap.c
I can move it into an appropriate header and use it here and in mmap.c
>
>> grub_uint64_t grub_rsdp_addr;
>>
>> @@ -30,6 +39,8 @@ static struct { char _entry[32]; } hypercall_page[128]
>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>
>> static grub_uint32_t xen_cpuid_base;
>> +static struct xen_machine_mmap_entry map[128];
>
> A constant instead of 128? If no why 128?
I can use a macro instead.
>
>> +static unsigned int nr_map_entries;
>>
>> static void
>> grub_xen_early_halt (void)
>> @@ -93,11 +104,98 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> return __res;
>> }
>>
>> +static void
>> +grub_xen_sort_mmap (void)
>> +{
>> + grub_uint64_t from, to;
>> + unsigned int i;
>> + struct xen_machine_mmap_entry tmp;
>> +
>> + /* Align map entries to page boundaries. */
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + from = map[i].addr;
>> + to = from + map[i].len;
>> + if (map[i].type == GRUB_MEMORY_AVAILABLE)
>> + {
>> + from = ALIGN_UP(from, GRUB_XEN_PAGE_SIZE);
>
> Lack of space between macro name and "(".
> Here and below...
Okay.
>
>> + to = ALIGN_DOWN(to, GRUB_XEN_PAGE_SIZE);
>> + }
>> + else
>> + {
>> + from = ALIGN_DOWN(from, GRUB_XEN_PAGE_SIZE);
>> + to = ALIGN_UP(to, GRUB_XEN_PAGE_SIZE);
>> + }
>> + map[i].addr = from;
>> + map[i].len = to - from;
>> + }
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 11/18] xen: get memory map from hypervisor for PVH
2018-10-19 12:40 ` Daniel Kiper
2018-10-19 15:06 ` Juergen Gross
@ 2018-10-19 15:06 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:06 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/2018 14:40, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:10PM +0200, Juergen Gross wrote:
>> Retrieve the memory map from the hypervisor and normalize it to contain
>> no overlapping entries and to be sorted by address.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 98 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 98 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index c1b1cf8db..b4933b454 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -22,7 +22,16 @@
>> #include <grub/mm.h>
>> #include <grub/i386/cpuid.h>
>> #include <grub/xen.h>
>> +#include <grub/i386/linux.h>
>> #include <grub/machine/kernel.h>
>> +#include <xen/memory.h>
>> +
>> +struct xen_machine_mmap_entry
>> +{
>> + grub_uint64_t addr;
>> + grub_uint64_t len;
>> + grub_uint32_t type;
>> +} GRUB_PACKED;
>
> Could not we reuse grub_e820_mmap_entry here?
This is defined only locally in grub-core/mmap/i386/pc/mmap.c
I can move it into an appropriate header and use it here and in mmap.c
>
>> grub_uint64_t grub_rsdp_addr;
>>
>> @@ -30,6 +39,8 @@ static struct { char _entry[32]; } hypercall_page[128]
>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>
>> static grub_uint32_t xen_cpuid_base;
>> +static struct xen_machine_mmap_entry map[128];
>
> A constant instead of 128? If no why 128?
I can use a macro instead.
>
>> +static unsigned int nr_map_entries;
>>
>> static void
>> grub_xen_early_halt (void)
>> @@ -93,11 +104,98 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> return __res;
>> }
>>
>> +static void
>> +grub_xen_sort_mmap (void)
>> +{
>> + grub_uint64_t from, to;
>> + unsigned int i;
>> + struct xen_machine_mmap_entry tmp;
>> +
>> + /* Align map entries to page boundaries. */
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + from = map[i].addr;
>> + to = from + map[i].len;
>> + if (map[i].type == GRUB_MEMORY_AVAILABLE)
>> + {
>> + from = ALIGN_UP(from, GRUB_XEN_PAGE_SIZE);
>
> Lack of space between macro name and "(".
> Here and below...
Okay.
>
>> + to = ALIGN_DOWN(to, GRUB_XEN_PAGE_SIZE);
>> + }
>> + else
>> + {
>> + from = ALIGN_DOWN(from, GRUB_XEN_PAGE_SIZE);
>> + to = ALIGN_UP(to, GRUB_XEN_PAGE_SIZE);
>> + }
>> + map[i].addr = from;
>> + map[i].len = to - from;
>> + }
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Initialize the needed Xen specific data. This is:
- the Xen start of day page containing the console and Xenstore ring
page PFN and event channel
- the grant table
- the shared info page
Set the RSDP address for the guest from the start_info page passed
as boot parameter.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index b4933b454..93ed68245 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -24,6 +24,7 @@
#include <grub/xen.h>
#include <grub/i386/linux.h>
#include <grub/machine/kernel.h>
+#include <xen/hvm/params.h>
#include <xen/memory.h>
struct xen_machine_mmap_entry
@@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
__attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
static grub_uint32_t xen_cpuid_base;
+static struct start_info grub_xen_start_page;
static struct xen_machine_mmap_entry map[128];
static unsigned int nr_map_entries;
@@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
return __res;
}
+static grub_uint32_t
+grub_xen_get_param (int idx)
+{
+ struct xen_hvm_param xhv;
+ int r;
+
+ xhv.domid = DOMID_SELF;
+ xhv.index = idx;
+ r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
+ (grub_uint32_t) (&xhv), 0, 0, 0, 0);
+ if (r < 0)
+ grub_xen_early_halt ();
+ return xhv.value;
+}
+
+static void *
+grub_xen_add_physmap (unsigned int space, void *addr)
+{
+ struct xen_add_to_physmap xatp;
+
+ xatp.domid = DOMID_SELF;
+ xatp.idx = 0;
+ xatp.space = space;
+ xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
+ if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
+ (grub_uint32_t) (&xatp), 0, 0, 0, 0))
+ grub_xen_early_halt ();
+ return addr;
+}
+
static void
grub_xen_sort_mmap (void)
{
@@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
grub_xen_sort_mmap ();
}
+static grub_uint64_t
+grub_xen_find_page (grub_uint64_t start)
+{
+ unsigned int i, j;
+ grub_uint64_t last = start;
+
+ /* Try to find a e820 map hole below 4G. */
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (last > map[i].addr + map[i].len)
+ continue;
+ if (last < map[i].addr)
+ return last;
+ if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
+ break;
+ last = map[i].addr + map[i].len;
+ }
+ if (i == nr_map_entries)
+ return last;
+
+ /* No hole found, use the highest RAM page below 4G and reserve it. */
+ if (nr_map_entries == ARRAY_SIZE(map))
+ grub_xen_early_halt ();
+ j = 0;
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (map[i].type != GRUB_MEMORY_AVAILABLE)
+ continue;
+ if (map[i].addr >> 32)
+ break;
+ j = i;
+ if ((map[i].addr + map[i].len) >> 32)
+ break;
+ }
+ if (map[j].type != GRUB_MEMORY_AVAILABLE)
+ grub_xen_early_halt ();
+ if ((map[i].addr + map[i].len) >> 32)
+ last = (1ULL << 32) - GRUB_XEN_PAGE_SIZE;
+ else
+ last = map[i].addr + map[i].len - GRUB_XEN_PAGE_SIZE;
+ map[nr_map_entries].addr = last;
+ map[nr_map_entries].len = GRUB_XEN_PAGE_SIZE;
+ map[nr_map_entries].type = GRUB_MEMORY_RESERVED;
+ nr_map_entries++;
+ grub_xen_sort_mmap ();
+
+ return last;
+}
+
void
grub_xen_setup_pvh (void)
{
+ grub_addr_t par;
+
grub_xen_cpuid_base ();
grub_xen_setup_hypercall_page ();
grub_xen_get_mmap ();
+
+ /* Setup Xen data. */
+ grub_xen_start_page_addr = &grub_xen_start_page;
+
+ par = grub_xen_get_param (HVM_PARAM_CONSOLE_PFN);
+ grub_xen_start_page_addr->console.domU.mfn = par;
+ grub_xen_xcons = (void *) (grub_addr_t) (par << GRUB_XEN_LOG_PAGE_SIZE);
+ par = grub_xen_get_param (HVM_PARAM_CONSOLE_EVTCHN);
+ grub_xen_start_page_addr->console.domU.evtchn = par;
+
+ par = grub_xen_get_param (HVM_PARAM_STORE_PFN);
+ grub_xen_start_page_addr->store_mfn = par;
+ grub_xen_xenstore = (void *) (grub_addr_t) (par << GRUB_XEN_LOG_PAGE_SIZE);
+ par = grub_xen_get_param (HVM_PARAM_STORE_EVTCHN);
+ grub_xen_start_page_addr->store_evtchn = par;
+
+ par = grub_xen_find_page (0);
+ grub_xen_grant_table = grub_xen_add_physmap (XENMAPSPACE_grant_table,
+ (void *) par);
+ par = grub_xen_find_page (par + GRUB_XEN_PAGE_SIZE);
+ grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
+ (void *) par);
+
+ grub_rsdp_addr = pvh_start_info->rsdp_paddr;
}
grub_err_t
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 12/18] xen: setup Xen specific data for PVH
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Initialize the needed Xen specific data. This is:
- the Xen start of day page containing the console and Xenstore ring
page PFN and event channel
- the grant table
- the shared info page
Set the RSDP address for the guest from the start_info page passed
as boot parameter.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index b4933b454..93ed68245 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -24,6 +24,7 @@
#include <grub/xen.h>
#include <grub/i386/linux.h>
#include <grub/machine/kernel.h>
+#include <xen/hvm/params.h>
#include <xen/memory.h>
struct xen_machine_mmap_entry
@@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
__attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
static grub_uint32_t xen_cpuid_base;
+static struct start_info grub_xen_start_page;
static struct xen_machine_mmap_entry map[128];
static unsigned int nr_map_entries;
@@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
return __res;
}
+static grub_uint32_t
+grub_xen_get_param (int idx)
+{
+ struct xen_hvm_param xhv;
+ int r;
+
+ xhv.domid = DOMID_SELF;
+ xhv.index = idx;
+ r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
+ (grub_uint32_t) (&xhv), 0, 0, 0, 0);
+ if (r < 0)
+ grub_xen_early_halt ();
+ return xhv.value;
+}
+
+static void *
+grub_xen_add_physmap (unsigned int space, void *addr)
+{
+ struct xen_add_to_physmap xatp;
+
+ xatp.domid = DOMID_SELF;
+ xatp.idx = 0;
+ xatp.space = space;
+ xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
+ if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
+ (grub_uint32_t) (&xatp), 0, 0, 0, 0))
+ grub_xen_early_halt ();
+ return addr;
+}
+
static void
grub_xen_sort_mmap (void)
{
@@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
grub_xen_sort_mmap ();
}
+static grub_uint64_t
+grub_xen_find_page (grub_uint64_t start)
+{
+ unsigned int i, j;
+ grub_uint64_t last = start;
+
+ /* Try to find a e820 map hole below 4G. */
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (last > map[i].addr + map[i].len)
+ continue;
+ if (last < map[i].addr)
+ return last;
+ if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
+ break;
+ last = map[i].addr + map[i].len;
+ }
+ if (i == nr_map_entries)
+ return last;
+
+ /* No hole found, use the highest RAM page below 4G and reserve it. */
+ if (nr_map_entries == ARRAY_SIZE(map))
+ grub_xen_early_halt ();
+ j = 0;
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (map[i].type != GRUB_MEMORY_AVAILABLE)
+ continue;
+ if (map[i].addr >> 32)
+ break;
+ j = i;
+ if ((map[i].addr + map[i].len) >> 32)
+ break;
+ }
+ if (map[j].type != GRUB_MEMORY_AVAILABLE)
+ grub_xen_early_halt ();
+ if ((map[i].addr + map[i].len) >> 32)
+ last = (1ULL << 32) - GRUB_XEN_PAGE_SIZE;
+ else
+ last = map[i].addr + map[i].len - GRUB_XEN_PAGE_SIZE;
+ map[nr_map_entries].addr = last;
+ map[nr_map_entries].len = GRUB_XEN_PAGE_SIZE;
+ map[nr_map_entries].type = GRUB_MEMORY_RESERVED;
+ nr_map_entries++;
+ grub_xen_sort_mmap ();
+
+ return last;
+}
+
void
grub_xen_setup_pvh (void)
{
+ grub_addr_t par;
+
grub_xen_cpuid_base ();
grub_xen_setup_hypercall_page ();
grub_xen_get_mmap ();
+
+ /* Setup Xen data. */
+ grub_xen_start_page_addr = &grub_xen_start_page;
+
+ par = grub_xen_get_param (HVM_PARAM_CONSOLE_PFN);
+ grub_xen_start_page_addr->console.domU.mfn = par;
+ grub_xen_xcons = (void *) (grub_addr_t) (par << GRUB_XEN_LOG_PAGE_SIZE);
+ par = grub_xen_get_param (HVM_PARAM_CONSOLE_EVTCHN);
+ grub_xen_start_page_addr->console.domU.evtchn = par;
+
+ par = grub_xen_get_param (HVM_PARAM_STORE_PFN);
+ grub_xen_start_page_addr->store_mfn = par;
+ grub_xen_xenstore = (void *) (grub_addr_t) (par << GRUB_XEN_LOG_PAGE_SIZE);
+ par = grub_xen_get_param (HVM_PARAM_STORE_EVTCHN);
+ grub_xen_start_page_addr->store_evtchn = par;
+
+ par = grub_xen_find_page (0);
+ grub_xen_grant_table = grub_xen_add_physmap (XENMAPSPACE_grant_table,
+ (void *) par);
+ par = grub_xen_find_page (par + GRUB_XEN_PAGE_SIZE);
+ grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
+ (void *) par);
+
+ grub_rsdp_addr = pvh_start_info->rsdp_paddr;
}
grub_err_t
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-19 12:48 ` Daniel Kiper
2018-10-19 15:10 ` [Xen-devel] " Juergen Gross
2018-10-19 15:10 ` Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:48 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index b4933b454..93ed68245 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -24,6 +24,7 @@
> #include <grub/xen.h>
> #include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/hvm/params.h>
> #include <xen/memory.h>
>
> struct xen_machine_mmap_entry
> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct start_info grub_xen_start_page;
> static struct xen_machine_mmap_entry map[128];
> static unsigned int nr_map_entries;
>
> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static grub_uint32_t
> +grub_xen_get_param (int idx)
> +{
> + struct xen_hvm_param xhv;
> + int r;
> +
> + xhv.domid = DOMID_SELF;
> + xhv.index = idx;
> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
s/(grub_uint32_t) (&xhv)/(grub_uint32_t)(&xhv)/
Here and in the other patches...
> + if (r < 0)
> + grub_xen_early_halt ();
> + return xhv.value;
> +}
> +
> +static void *
> +grub_xen_add_physmap (unsigned int space, void *addr)
> +{
> + struct xen_add_to_physmap xatp;
> +
> + xatp.domid = DOMID_SELF;
> + xatp.idx = 0;
> + xatp.space = space;
> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> + grub_xen_early_halt ();
> + return addr;
> +}
> +
> static void
> grub_xen_sort_mmap (void)
> {
> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> grub_xen_sort_mmap ();
> }
>
> +static grub_uint64_t
> +grub_xen_find_page (grub_uint64_t start)
> +{
> + unsigned int i, j;
> + grub_uint64_t last = start;
> +
> + /* Try to find a e820 map hole below 4G. */
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (last > map[i].addr + map[i].len)
> + continue;
> + if (last < map[i].addr)
> + return last;
> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
> + break;
> + last = map[i].addr + map[i].len;
> + }
> + if (i == nr_map_entries)
> + return last;
> +
> + /* No hole found, use the highest RAM page below 4G and reserve it. */
It seems to me that this comment should be put before next for().
> + if (nr_map_entries == ARRAY_SIZE(map))
> + grub_xen_early_halt ();
> + j = 0;
> + for (i = 0; i < nr_map_entries; i++)
for (i = 0, j = 0; i < nr_map_entries; i++)
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-19 12:48 ` Daniel Kiper
@ 2018-10-19 15:10 ` Juergen Gross
2018-10-24 14:01 ` [Xen-devel] " Juergen Gross
2018-10-19 15:10 ` Juergen Gross
1 sibling, 1 reply; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:10 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/2018 14:48, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>> Initialize the needed Xen specific data. This is:
>>
>> - the Xen start of day page containing the console and Xenstore ring
>> page PFN and event channel
>> - the grant table
>> - the shared info page
>>
>> Set the RSDP address for the guest from the start_info page passed
>> as boot parameter.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index b4933b454..93ed68245 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -24,6 +24,7 @@
>> #include <grub/xen.h>
>> #include <grub/i386/linux.h>
>> #include <grub/machine/kernel.h>
>> +#include <xen/hvm/params.h>
>> #include <xen/memory.h>
>>
>> struct xen_machine_mmap_entry
>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>
>> static grub_uint32_t xen_cpuid_base;
>> +static struct start_info grub_xen_start_page;
>> static struct xen_machine_mmap_entry map[128];
>> static unsigned int nr_map_entries;
>>
>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> return __res;
>> }
>>
>> +static grub_uint32_t
>> +grub_xen_get_param (int idx)
>> +{
>> + struct xen_hvm_param xhv;
>> + int r;
>> +
>> + xhv.domid = DOMID_SELF;
>> + xhv.index = idx;
>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>
> s/(grub_uint32_t) (&xhv)/(grub_uint32_t)(&xhv)/
> Here and in the other patches...
Oh, I have seen lots of places where casts are followed by a blank. I
thought this would be the preferred style.
>
>> + if (r < 0)
>> + grub_xen_early_halt ();
>> + return xhv.value;
>> +}
>> +
>> +static void *
>> +grub_xen_add_physmap (unsigned int space, void *addr)
>> +{
>> + struct xen_add_to_physmap xatp;
>> +
>> + xatp.domid = DOMID_SELF;
>> + xatp.idx = 0;
>> + xatp.space = space;
>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>> + grub_xen_early_halt ();
>> + return addr;
>> +}
>> +
>> static void
>> grub_xen_sort_mmap (void)
>> {
>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>> grub_xen_sort_mmap ();
>> }
>>
>> +static grub_uint64_t
>> +grub_xen_find_page (grub_uint64_t start)
>> +{
>> + unsigned int i, j;
>> + grub_uint64_t last = start;
>> +
>> + /* Try to find a e820 map hole below 4G. */
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (last > map[i].addr + map[i].len)
>> + continue;
>> + if (last < map[i].addr)
>> + return last;
>> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
>> + break;
>> + last = map[i].addr + map[i].len;
>> + }
>> + if (i == nr_map_entries)
>> + return last;
>> +
>> + /* No hole found, use the highest RAM page below 4G and reserve it. */
>
> It seems to me that this comment should be put before next for().
Hmm, that's a matter of taste, I think. The comment is at the point
where the "no hole found" case is started to be handled. I can move
it down, of course.
>
>> + if (nr_map_entries == ARRAY_SIZE(map))
>> + grub_xen_early_halt ();
>> + j = 0;
>> + for (i = 0; i < nr_map_entries; i++)
>
> for (i = 0, j = 0; i < nr_map_entries; i++)
Okay.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-19 15:10 ` [Xen-devel] " Juergen Gross
@ 2018-10-24 14:01 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-24 14:01 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 19/10/2018 17:10, Juergen Gross wrote:
> On 19/10/2018 14:48, Daniel Kiper wrote:
>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>>
>> s/(grub_uint32_t) (&xhv)/(grub_uint32_t)(&xhv)/
>> Here and in the other patches...
>
> Oh, I have seen lots of places where casts are followed by a blank. I
> thought this would be the preferred style.
Doing some greps I've found about 9000 casts with a blank between
(type) and casted value, but less than 3000 omitting the blank.
Is omitting the blank really preferred?
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
@ 2018-10-24 14:01 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-24 14:01 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/2018 17:10, Juergen Gross wrote:
> On 19/10/2018 14:48, Daniel Kiper wrote:
>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>>
>> s/(grub_uint32_t) (&xhv)/(grub_uint32_t)(&xhv)/
>> Here and in the other patches...
>
> Oh, I have seen lots of places where casts are followed by a blank. I
> thought this would be the preferred style.
Doing some greps I've found about 9000 casts with a blank between
(type) and casted value, but less than 3000 omitting the blank.
Is omitting the blank really preferred?
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-19 12:48 ` Daniel Kiper
2018-10-19 15:10 ` [Xen-devel] " Juergen Gross
@ 2018-10-19 15:10 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 15:10 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, xen-devel, phcoder
On 19/10/2018 14:48, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>> Initialize the needed Xen specific data. This is:
>>
>> - the Xen start of day page containing the console and Xenstore ring
>> page PFN and event channel
>> - the grant table
>> - the shared info page
>>
>> Set the RSDP address for the guest from the start_info page passed
>> as boot parameter.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index b4933b454..93ed68245 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -24,6 +24,7 @@
>> #include <grub/xen.h>
>> #include <grub/i386/linux.h>
>> #include <grub/machine/kernel.h>
>> +#include <xen/hvm/params.h>
>> #include <xen/memory.h>
>>
>> struct xen_machine_mmap_entry
>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>
>> static grub_uint32_t xen_cpuid_base;
>> +static struct start_info grub_xen_start_page;
>> static struct xen_machine_mmap_entry map[128];
>> static unsigned int nr_map_entries;
>>
>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> return __res;
>> }
>>
>> +static grub_uint32_t
>> +grub_xen_get_param (int idx)
>> +{
>> + struct xen_hvm_param xhv;
>> + int r;
>> +
>> + xhv.domid = DOMID_SELF;
>> + xhv.index = idx;
>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>
> s/(grub_uint32_t) (&xhv)/(grub_uint32_t)(&xhv)/
> Here and in the other patches...
Oh, I have seen lots of places where casts are followed by a blank. I
thought this would be the preferred style.
>
>> + if (r < 0)
>> + grub_xen_early_halt ();
>> + return xhv.value;
>> +}
>> +
>> +static void *
>> +grub_xen_add_physmap (unsigned int space, void *addr)
>> +{
>> + struct xen_add_to_physmap xatp;
>> +
>> + xatp.domid = DOMID_SELF;
>> + xatp.idx = 0;
>> + xatp.space = space;
>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>> + grub_xen_early_halt ();
>> + return addr;
>> +}
>> +
>> static void
>> grub_xen_sort_mmap (void)
>> {
>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>> grub_xen_sort_mmap ();
>> }
>>
>> +static grub_uint64_t
>> +grub_xen_find_page (grub_uint64_t start)
>> +{
>> + unsigned int i, j;
>> + grub_uint64_t last = start;
>> +
>> + /* Try to find a e820 map hole below 4G. */
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (last > map[i].addr + map[i].len)
>> + continue;
>> + if (last < map[i].addr)
>> + return last;
>> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
>> + break;
>> + last = map[i].addr + map[i].len;
>> + }
>> + if (i == nr_map_entries)
>> + return last;
>> +
>> + /* No hole found, use the highest RAM page below 4G and reserve it. */
>
> It seems to me that this comment should be put before next for().
Hmm, that's a matter of taste, I think. The comment is at the point
where the "no hole found" case is started to be handled. I can move
it down, of course.
>
>> + if (nr_map_entries == ARRAY_SIZE(map))
>> + grub_xen_early_halt ();
>> + j = 0;
>> + for (i = 0; i < nr_map_entries; i++)
>
> for (i = 0, j = 0; i < nr_map_entries; i++)
Okay.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-19 12:48 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-19 12:48 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index b4933b454..93ed68245 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -24,6 +24,7 @@
> #include <grub/xen.h>
> #include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/hvm/params.h>
> #include <xen/memory.h>
>
> struct xen_machine_mmap_entry
> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct start_info grub_xen_start_page;
> static struct xen_machine_mmap_entry map[128];
> static unsigned int nr_map_entries;
>
> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static grub_uint32_t
> +grub_xen_get_param (int idx)
> +{
> + struct xen_hvm_param xhv;
> + int r;
> +
> + xhv.domid = DOMID_SELF;
> + xhv.index = idx;
> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
s/(grub_uint32_t) (&xhv)/(grub_uint32_t)(&xhv)/
Here and in the other patches...
> + if (r < 0)
> + grub_xen_early_halt ();
> + return xhv.value;
> +}
> +
> +static void *
> +grub_xen_add_physmap (unsigned int space, void *addr)
> +{
> + struct xen_add_to_physmap xatp;
> +
> + xatp.domid = DOMID_SELF;
> + xatp.idx = 0;
> + xatp.space = space;
> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> + grub_xen_early_halt ();
> + return addr;
> +}
> +
> static void
> grub_xen_sort_mmap (void)
> {
> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> grub_xen_sort_mmap ();
> }
>
> +static grub_uint64_t
> +grub_xen_find_page (grub_uint64_t start)
> +{
> + unsigned int i, j;
> + grub_uint64_t last = start;
> +
> + /* Try to find a e820 map hole below 4G. */
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (last > map[i].addr + map[i].len)
> + continue;
> + if (last < map[i].addr)
> + return last;
> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
> + break;
> + last = map[i].addr + map[i].len;
> + }
> + if (i == nr_map_entries)
> + return last;
> +
> + /* No hole found, use the highest RAM page below 4G and reserve it. */
It seems to me that this comment should be put before next for().
> + if (nr_map_entries == ARRAY_SIZE(map))
> + grub_xen_early_halt ();
> + j = 0;
> + for (i = 0; i < nr_map_entries; i++)
for (i = 0, j = 0; i < nr_map_entries; i++)
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-09 11:03 ` Juergen Gross
` (2 preceding siblings ...)
(?)
@ 2018-10-19 15:46 ` Roger Pau Monné
-1 siblings, 0 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 15:46 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index b4933b454..93ed68245 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -24,6 +24,7 @@
> #include <grub/xen.h>
> #include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/hvm/params.h>
> #include <xen/memory.h>
>
> struct xen_machine_mmap_entry
> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct start_info grub_xen_start_page;
> static struct xen_machine_mmap_entry map[128];
> static unsigned int nr_map_entries;
>
> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static grub_uint32_t
> +grub_xen_get_param (int idx)
> +{
> + struct xen_hvm_param xhv;
> + int r;
> +
> + xhv.domid = DOMID_SELF;
> + xhv.index = idx;
> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> + if (r < 0)
> + grub_xen_early_halt ();
At this point you already have access to the hypervisor console from
the hypercall page, or alternatively you can use the 0xe9 IO port, IMO
a debug message should be printed instead of just halting. Or else
debugging failures is going to be quite complicated.
I would suggest to convert grub_xen_early_halt into
grub_xen_early_crash and make it a printf like function, or at least
take a string.
Thanks, Roger.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-09 11:03 ` Juergen Gross
` (3 preceding siblings ...)
(?)
@ 2018-10-19 15:46 ` Roger Pau Monné
-1 siblings, 0 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 15:46 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index b4933b454..93ed68245 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -24,6 +24,7 @@
> #include <grub/xen.h>
> #include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/hvm/params.h>
> #include <xen/memory.h>
>
> struct xen_machine_mmap_entry
> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct start_info grub_xen_start_page;
> static struct xen_machine_mmap_entry map[128];
> static unsigned int nr_map_entries;
>
> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static grub_uint32_t
> +grub_xen_get_param (int idx)
> +{
> + struct xen_hvm_param xhv;
> + int r;
> +
> + xhv.domid = DOMID_SELF;
> + xhv.index = idx;
> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> + if (r < 0)
> + grub_xen_early_halt ();
At this point you already have access to the hypervisor console from
the hypercall page, or alternatively you can use the 0xe9 IO port, IMO
a debug message should be printed instead of just halting. Or else
debugging failures is going to be quite complicated.
I would suggest to convert grub_xen_early_halt into
grub_xen_early_crash and make it a printf like function, or at least
take a string.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-09 11:03 ` Juergen Gross
` (4 preceding siblings ...)
(?)
@ 2018-10-19 16:10 ` Roger Pau Monné
-1 siblings, 0 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 16:10 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index b4933b454..93ed68245 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -24,6 +24,7 @@
> #include <grub/xen.h>
> #include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/hvm/params.h>
> #include <xen/memory.h>
>
> struct xen_machine_mmap_entry
> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct start_info grub_xen_start_page;
> static struct xen_machine_mmap_entry map[128];
> static unsigned int nr_map_entries;
>
> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static grub_uint32_t
> +grub_xen_get_param (int idx)
> +{
> + struct xen_hvm_param xhv;
> + int r;
> +
> + xhv.domid = DOMID_SELF;
> + xhv.index = idx;
> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> + if (r < 0)
> + grub_xen_early_halt ();
> + return xhv.value;
> +}
> +
> +static void *
> +grub_xen_add_physmap (unsigned int space, void *addr)
> +{
> + struct xen_add_to_physmap xatp;
> +
> + xatp.domid = DOMID_SELF;
> + xatp.idx = 0;
> + xatp.space = space;
> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> + grub_xen_early_halt ();
> + return addr;
> +}
> +
> static void
> grub_xen_sort_mmap (void)
> {
> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> grub_xen_sort_mmap ();
> }
>
> +static grub_uint64_t
> +grub_xen_find_page (grub_uint64_t start)
> +{
> + unsigned int i, j;
> + grub_uint64_t last = start;
> +
> + /* Try to find a e820 map hole below 4G. */
Doing this is kind of dangerous, what if you end up placing something
on top of an MMIO region (either emulated or from a real passthrough
device)?
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (last > map[i].addr + map[i].len)
> + continue;
> + if (last < map[i].addr)
> + return last;
> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
> + break;
> + last = map[i].addr + map[i].len;
> + }
> + if (i == nr_map_entries)
> + return last;
> +
> + /* No hole found, use the highest RAM page below 4G and reserve it. */
I would rather use a RAM page and populate if afterwards, so that the
memory map returned by the Xen hypercall still matches the current
physmap, or else update the memmap using XENMEM_set_memory_map?
This has the nasty side effect of shattering the p2m though.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-09 11:03 ` Juergen Gross
` (5 preceding siblings ...)
(?)
@ 2018-10-19 16:10 ` Roger Pau Monné
2018-10-19 16:39 ` [Xen-devel] " Juergen Gross
-1 siblings, 1 reply; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-19 16:10 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index b4933b454..93ed68245 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -24,6 +24,7 @@
> #include <grub/xen.h>
> #include <grub/i386/linux.h>
> #include <grub/machine/kernel.h>
> +#include <xen/hvm/params.h>
> #include <xen/memory.h>
>
> struct xen_machine_mmap_entry
> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct start_info grub_xen_start_page;
> static struct xen_machine_mmap_entry map[128];
> static unsigned int nr_map_entries;
>
> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> return __res;
> }
>
> +static grub_uint32_t
> +grub_xen_get_param (int idx)
> +{
> + struct xen_hvm_param xhv;
> + int r;
> +
> + xhv.domid = DOMID_SELF;
> + xhv.index = idx;
> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> + if (r < 0)
> + grub_xen_early_halt ();
> + return xhv.value;
> +}
> +
> +static void *
> +grub_xen_add_physmap (unsigned int space, void *addr)
> +{
> + struct xen_add_to_physmap xatp;
> +
> + xatp.domid = DOMID_SELF;
> + xatp.idx = 0;
> + xatp.space = space;
> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> + grub_xen_early_halt ();
> + return addr;
> +}
> +
> static void
> grub_xen_sort_mmap (void)
> {
> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> grub_xen_sort_mmap ();
> }
>
> +static grub_uint64_t
> +grub_xen_find_page (grub_uint64_t start)
> +{
> + unsigned int i, j;
> + grub_uint64_t last = start;
> +
> + /* Try to find a e820 map hole below 4G. */
Doing this is kind of dangerous, what if you end up placing something
on top of an MMIO region (either emulated or from a real passthrough
device)?
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (last > map[i].addr + map[i].len)
> + continue;
> + if (last < map[i].addr)
> + return last;
> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
> + break;
> + last = map[i].addr + map[i].len;
> + }
> + if (i == nr_map_entries)
> + return last;
> +
> + /* No hole found, use the highest RAM page below 4G and reserve it. */
I would rather use a RAM page and populate if afterwards, so that the
memory map returned by the Xen hypercall still matches the current
physmap, or else update the memmap using XENMEM_set_memory_map?
This has the nasty side effect of shattering the p2m though.
Thanks, Roger.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-19 16:10 ` [Xen-devel] " Roger Pau Monné
@ 2018-10-19 16:39 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 16:39 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On 19/10/2018 18:10, Roger Pau Monné wrote:
> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>> Initialize the needed Xen specific data. This is:
>>
>> - the Xen start of day page containing the console and Xenstore ring
>> page PFN and event channel
>> - the grant table
>> - the shared info page
>>
>> Set the RSDP address for the guest from the start_info page passed
>> as boot parameter.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index b4933b454..93ed68245 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -24,6 +24,7 @@
>> #include <grub/xen.h>
>> #include <grub/i386/linux.h>
>> #include <grub/machine/kernel.h>
>> +#include <xen/hvm/params.h>
>> #include <xen/memory.h>
>>
>> struct xen_machine_mmap_entry
>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>
>> static grub_uint32_t xen_cpuid_base;
>> +static struct start_info grub_xen_start_page;
>> static struct xen_machine_mmap_entry map[128];
>> static unsigned int nr_map_entries;
>>
>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> return __res;
>> }
>>
>> +static grub_uint32_t
>> +grub_xen_get_param (int idx)
>> +{
>> + struct xen_hvm_param xhv;
>> + int r;
>> +
>> + xhv.domid = DOMID_SELF;
>> + xhv.index = idx;
>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>> + if (r < 0)
>> + grub_xen_early_halt ();
>> + return xhv.value;
>> +}
>> +
>> +static void *
>> +grub_xen_add_physmap (unsigned int space, void *addr)
>> +{
>> + struct xen_add_to_physmap xatp;
>> +
>> + xatp.domid = DOMID_SELF;
>> + xatp.idx = 0;
>> + xatp.space = space;
>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>> + grub_xen_early_halt ();
>> + return addr;
>> +}
>> +
>> static void
>> grub_xen_sort_mmap (void)
>> {
>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>> grub_xen_sort_mmap ();
>> }
>>
>> +static grub_uint64_t
>> +grub_xen_find_page (grub_uint64_t start)
>> +{
>> + unsigned int i, j;
>> + grub_uint64_t last = start;
>> +
>> + /* Try to find a e820 map hole below 4G. */
>
> Doing this is kind of dangerous, what if you end up placing something
> on top of an MMIO region (either emulated or from a real passthrough
> device)?
Shouldn't those be marked as "Reserved" in the memory map?
>
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (last > map[i].addr + map[i].len)
>> + continue;
>> + if (last < map[i].addr)
>> + return last;
>> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
>> + break;
>> + last = map[i].addr + map[i].len;
>> + }
>> + if (i == nr_map_entries)
>> + return last;
>> +
>> + /* No hole found, use the highest RAM page below 4G and reserve it. */
>
> I would rather use a RAM page and populate if afterwards, so that the
> memory map returned by the Xen hypercall still matches the current
> physmap, or else update the memmap using XENMEM_set_memory_map?
>
> This has the nasty side effect of shattering the p2m though.
Right, and this would be a noticeable performance hit.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
@ 2018-10-19 16:39 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-19 16:39 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On 19/10/2018 18:10, Roger Pau Monné wrote:
> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>> Initialize the needed Xen specific data. This is:
>>
>> - the Xen start of day page containing the console and Xenstore ring
>> page PFN and event channel
>> - the grant table
>> - the shared info page
>>
>> Set the RSDP address for the guest from the start_info page passed
>> as boot parameter.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index b4933b454..93ed68245 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -24,6 +24,7 @@
>> #include <grub/xen.h>
>> #include <grub/i386/linux.h>
>> #include <grub/machine/kernel.h>
>> +#include <xen/hvm/params.h>
>> #include <xen/memory.h>
>>
>> struct xen_machine_mmap_entry
>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>
>> static grub_uint32_t xen_cpuid_base;
>> +static struct start_info grub_xen_start_page;
>> static struct xen_machine_mmap_entry map[128];
>> static unsigned int nr_map_entries;
>>
>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>> return __res;
>> }
>>
>> +static grub_uint32_t
>> +grub_xen_get_param (int idx)
>> +{
>> + struct xen_hvm_param xhv;
>> + int r;
>> +
>> + xhv.domid = DOMID_SELF;
>> + xhv.index = idx;
>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>> + if (r < 0)
>> + grub_xen_early_halt ();
>> + return xhv.value;
>> +}
>> +
>> +static void *
>> +grub_xen_add_physmap (unsigned int space, void *addr)
>> +{
>> + struct xen_add_to_physmap xatp;
>> +
>> + xatp.domid = DOMID_SELF;
>> + xatp.idx = 0;
>> + xatp.space = space;
>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>> + grub_xen_early_halt ();
>> + return addr;
>> +}
>> +
>> static void
>> grub_xen_sort_mmap (void)
>> {
>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>> grub_xen_sort_mmap ();
>> }
>>
>> +static grub_uint64_t
>> +grub_xen_find_page (grub_uint64_t start)
>> +{
>> + unsigned int i, j;
>> + grub_uint64_t last = start;
>> +
>> + /* Try to find a e820 map hole below 4G. */
>
> Doing this is kind of dangerous, what if you end up placing something
> on top of an MMIO region (either emulated or from a real passthrough
> device)?
Shouldn't those be marked as "Reserved" in the memory map?
>
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (last > map[i].addr + map[i].len)
>> + continue;
>> + if (last < map[i].addr)
>> + return last;
>> + if ((map[i].addr >> 32) || ((map[i].addr + map[i].len) >> 32))
>> + break;
>> + last = map[i].addr + map[i].len;
>> + }
>> + if (i == nr_map_entries)
>> + return last;
>> +
>> + /* No hole found, use the highest RAM page below 4G and reserve it. */
>
> I would rather use a RAM page and populate if afterwards, so that the
> memory map returned by the Xen hypercall still matches the current
> physmap, or else update the memmap using XENMEM_set_memory_map?
>
> This has the nasty side effect of shattering the p2m though.
Right, and this would be a noticeable performance hit.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-19 16:39 ` [Xen-devel] " Juergen Gross
(?)
@ 2018-10-29 12:57 ` Roger Pau Monné
-1 siblings, 0 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-29 12:57 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
> On 19/10/2018 18:10, Roger Pau Monné wrote:
> > On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> >> Initialize the needed Xen specific data. This is:
> >>
> >> - the Xen start of day page containing the console and Xenstore ring
> >> page PFN and event channel
> >> - the grant table
> >> - the shared info page
> >>
> >> Set the RSDP address for the guest from the start_info page passed
> >> as boot parameter.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 107 insertions(+)
> >>
> >> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >> index b4933b454..93ed68245 100644
> >> --- a/grub-core/kern/i386/xen/pvh.c
> >> +++ b/grub-core/kern/i386/xen/pvh.c
> >> @@ -24,6 +24,7 @@
> >> #include <grub/xen.h>
> >> #include <grub/i386/linux.h>
> >> #include <grub/machine/kernel.h>
> >> +#include <xen/hvm/params.h>
> >> #include <xen/memory.h>
> >>
> >> struct xen_machine_mmap_entry
> >> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> >> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> >>
> >> static grub_uint32_t xen_cpuid_base;
> >> +static struct start_info grub_xen_start_page;
> >> static struct xen_machine_mmap_entry map[128];
> >> static unsigned int nr_map_entries;
> >>
> >> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> >> return __res;
> >> }
> >>
> >> +static grub_uint32_t
> >> +grub_xen_get_param (int idx)
> >> +{
> >> + struct xen_hvm_param xhv;
> >> + int r;
> >> +
> >> + xhv.domid = DOMID_SELF;
> >> + xhv.index = idx;
> >> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> >> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> >> + if (r < 0)
> >> + grub_xen_early_halt ();
> >> + return xhv.value;
> >> +}
> >> +
> >> +static void *
> >> +grub_xen_add_physmap (unsigned int space, void *addr)
> >> +{
> >> + struct xen_add_to_physmap xatp;
> >> +
> >> + xatp.domid = DOMID_SELF;
> >> + xatp.idx = 0;
> >> + xatp.space = space;
> >> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> >> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> >> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> >> + grub_xen_early_halt ();
> >> + return addr;
> >> +}
> >> +
> >> static void
> >> grub_xen_sort_mmap (void)
> >> {
> >> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> >> grub_xen_sort_mmap ();
> >> }
> >>
> >> +static grub_uint64_t
> >> +grub_xen_find_page (grub_uint64_t start)
> >> +{
> >> + unsigned int i, j;
> >> + grub_uint64_t last = start;
> >> +
> >> + /* Try to find a e820 map hole below 4G. */
> >
> > Doing this is kind of dangerous, what if you end up placing something
> > on top of an MMIO region (either emulated or from a real passthrough
> > device)?
>
> Shouldn't those be marked as "Reserved" in the memory map?
I don't think BARs are guaranteed to be in areas marked as reserved in
the memory map. Unless you also scan for PCI devices and make sure
there's no device with a BAR in the area you are attempting to
populate I think the above is not safe.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-19 16:39 ` [Xen-devel] " Juergen Gross
(?)
(?)
@ 2018-10-29 12:57 ` Roger Pau Monné
2018-10-29 14:19 ` [Xen-devel] " Juergen Gross
-1 siblings, 1 reply; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-29 12:57 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
> On 19/10/2018 18:10, Roger Pau Monné wrote:
> > On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> >> Initialize the needed Xen specific data. This is:
> >>
> >> - the Xen start of day page containing the console and Xenstore ring
> >> page PFN and event channel
> >> - the grant table
> >> - the shared info page
> >>
> >> Set the RSDP address for the guest from the start_info page passed
> >> as boot parameter.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >> ---
> >> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 107 insertions(+)
> >>
> >> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >> index b4933b454..93ed68245 100644
> >> --- a/grub-core/kern/i386/xen/pvh.c
> >> +++ b/grub-core/kern/i386/xen/pvh.c
> >> @@ -24,6 +24,7 @@
> >> #include <grub/xen.h>
> >> #include <grub/i386/linux.h>
> >> #include <grub/machine/kernel.h>
> >> +#include <xen/hvm/params.h>
> >> #include <xen/memory.h>
> >>
> >> struct xen_machine_mmap_entry
> >> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> >> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> >>
> >> static grub_uint32_t xen_cpuid_base;
> >> +static struct start_info grub_xen_start_page;
> >> static struct xen_machine_mmap_entry map[128];
> >> static unsigned int nr_map_entries;
> >>
> >> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> >> return __res;
> >> }
> >>
> >> +static grub_uint32_t
> >> +grub_xen_get_param (int idx)
> >> +{
> >> + struct xen_hvm_param xhv;
> >> + int r;
> >> +
> >> + xhv.domid = DOMID_SELF;
> >> + xhv.index = idx;
> >> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> >> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> >> + if (r < 0)
> >> + grub_xen_early_halt ();
> >> + return xhv.value;
> >> +}
> >> +
> >> +static void *
> >> +grub_xen_add_physmap (unsigned int space, void *addr)
> >> +{
> >> + struct xen_add_to_physmap xatp;
> >> +
> >> + xatp.domid = DOMID_SELF;
> >> + xatp.idx = 0;
> >> + xatp.space = space;
> >> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> >> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> >> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> >> + grub_xen_early_halt ();
> >> + return addr;
> >> +}
> >> +
> >> static void
> >> grub_xen_sort_mmap (void)
> >> {
> >> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> >> grub_xen_sort_mmap ();
> >> }
> >>
> >> +static grub_uint64_t
> >> +grub_xen_find_page (grub_uint64_t start)
> >> +{
> >> + unsigned int i, j;
> >> + grub_uint64_t last = start;
> >> +
> >> + /* Try to find a e820 map hole below 4G. */
> >
> > Doing this is kind of dangerous, what if you end up placing something
> > on top of an MMIO region (either emulated or from a real passthrough
> > device)?
>
> Shouldn't those be marked as "Reserved" in the memory map?
I don't think BARs are guaranteed to be in areas marked as reserved in
the memory map. Unless you also scan for PCI devices and make sure
there's no device with a BAR in the area you are attempting to
populate I think the above is not safe.
Thanks, Roger.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-29 12:57 ` [Xen-devel] " Roger Pau Monné
@ 2018-10-29 14:19 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-29 14:19 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On 29/10/2018 13:57, Roger Pau Monné wrote:
> On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
>> On 19/10/2018 18:10, Roger Pau Monné wrote:
>>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>>>> Initialize the needed Xen specific data. This is:
>>>>
>>>> - the Xen start of day page containing the console and Xenstore ring
>>>> page PFN and event channel
>>>> - the grant table
>>>> - the shared info page
>>>>
>>>> Set the RSDP address for the guest from the start_info page passed
>>>> as boot parameter.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 107 insertions(+)
>>>>
>>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>>>> index b4933b454..93ed68245 100644
>>>> --- a/grub-core/kern/i386/xen/pvh.c
>>>> +++ b/grub-core/kern/i386/xen/pvh.c
>>>> @@ -24,6 +24,7 @@
>>>> #include <grub/xen.h>
>>>> #include <grub/i386/linux.h>
>>>> #include <grub/machine/kernel.h>
>>>> +#include <xen/hvm/params.h>
>>>> #include <xen/memory.h>
>>>>
>>>> struct xen_machine_mmap_entry
>>>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>>>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>>>
>>>> static grub_uint32_t xen_cpuid_base;
>>>> +static struct start_info grub_xen_start_page;
>>>> static struct xen_machine_mmap_entry map[128];
>>>> static unsigned int nr_map_entries;
>>>>
>>>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>>>> return __res;
>>>> }
>>>>
>>>> +static grub_uint32_t
>>>> +grub_xen_get_param (int idx)
>>>> +{
>>>> + struct xen_hvm_param xhv;
>>>> + int r;
>>>> +
>>>> + xhv.domid = DOMID_SELF;
>>>> + xhv.index = idx;
>>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>>>> + if (r < 0)
>>>> + grub_xen_early_halt ();
>>>> + return xhv.value;
>>>> +}
>>>> +
>>>> +static void *
>>>> +grub_xen_add_physmap (unsigned int space, void *addr)
>>>> +{
>>>> + struct xen_add_to_physmap xatp;
>>>> +
>>>> + xatp.domid = DOMID_SELF;
>>>> + xatp.idx = 0;
>>>> + xatp.space = space;
>>>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>>>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>>>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>>>> + grub_xen_early_halt ();
>>>> + return addr;
>>>> +}
>>>> +
>>>> static void
>>>> grub_xen_sort_mmap (void)
>>>> {
>>>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>>>> grub_xen_sort_mmap ();
>>>> }
>>>>
>>>> +static grub_uint64_t
>>>> +grub_xen_find_page (grub_uint64_t start)
>>>> +{
>>>> + unsigned int i, j;
>>>> + grub_uint64_t last = start;
>>>> +
>>>> + /* Try to find a e820 map hole below 4G. */
>>>
>>> Doing this is kind of dangerous, what if you end up placing something
>>> on top of an MMIO region (either emulated or from a real passthrough
>>> device)?
>>
>> Shouldn't those be marked as "Reserved" in the memory map?
>
> I don't think BARs are guaranteed to be in areas marked as reserved in
> the memory map. Unless you also scan for PCI devices and make sure
> there's no device with a BAR in the area you are attempting to
> populate I think the above is not safe.
So either I can add scanning the PCI bus (which wouldn't be too
hard IMO), or we require Xen tools to add memory map entries with
"Reserved" attribute for passed-through PCI device's MMIO-areas
(we can still do that as PCI pass-through for PVH isn't possible
yet AFAIK).
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
@ 2018-10-29 14:19 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-29 14:19 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On 29/10/2018 13:57, Roger Pau Monné wrote:
> On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
>> On 19/10/2018 18:10, Roger Pau Monné wrote:
>>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>>>> Initialize the needed Xen specific data. This is:
>>>>
>>>> - the Xen start of day page containing the console and Xenstore ring
>>>> page PFN and event channel
>>>> - the grant table
>>>> - the shared info page
>>>>
>>>> Set the RSDP address for the guest from the start_info page passed
>>>> as boot parameter.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 107 insertions(+)
>>>>
>>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>>>> index b4933b454..93ed68245 100644
>>>> --- a/grub-core/kern/i386/xen/pvh.c
>>>> +++ b/grub-core/kern/i386/xen/pvh.c
>>>> @@ -24,6 +24,7 @@
>>>> #include <grub/xen.h>
>>>> #include <grub/i386/linux.h>
>>>> #include <grub/machine/kernel.h>
>>>> +#include <xen/hvm/params.h>
>>>> #include <xen/memory.h>
>>>>
>>>> struct xen_machine_mmap_entry
>>>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>>>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>>>
>>>> static grub_uint32_t xen_cpuid_base;
>>>> +static struct start_info grub_xen_start_page;
>>>> static struct xen_machine_mmap_entry map[128];
>>>> static unsigned int nr_map_entries;
>>>>
>>>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>>>> return __res;
>>>> }
>>>>
>>>> +static grub_uint32_t
>>>> +grub_xen_get_param (int idx)
>>>> +{
>>>> + struct xen_hvm_param xhv;
>>>> + int r;
>>>> +
>>>> + xhv.domid = DOMID_SELF;
>>>> + xhv.index = idx;
>>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>>>> + if (r < 0)
>>>> + grub_xen_early_halt ();
>>>> + return xhv.value;
>>>> +}
>>>> +
>>>> +static void *
>>>> +grub_xen_add_physmap (unsigned int space, void *addr)
>>>> +{
>>>> + struct xen_add_to_physmap xatp;
>>>> +
>>>> + xatp.domid = DOMID_SELF;
>>>> + xatp.idx = 0;
>>>> + xatp.space = space;
>>>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>>>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>>>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>>>> + grub_xen_early_halt ();
>>>> + return addr;
>>>> +}
>>>> +
>>>> static void
>>>> grub_xen_sort_mmap (void)
>>>> {
>>>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>>>> grub_xen_sort_mmap ();
>>>> }
>>>>
>>>> +static grub_uint64_t
>>>> +grub_xen_find_page (grub_uint64_t start)
>>>> +{
>>>> + unsigned int i, j;
>>>> + grub_uint64_t last = start;
>>>> +
>>>> + /* Try to find a e820 map hole below 4G. */
>>>
>>> Doing this is kind of dangerous, what if you end up placing something
>>> on top of an MMIO region (either emulated or from a real passthrough
>>> device)?
>>
>> Shouldn't those be marked as "Reserved" in the memory map?
>
> I don't think BARs are guaranteed to be in areas marked as reserved in
> the memory map. Unless you also scan for PCI devices and make sure
> there's no device with a BAR in the area you are attempting to
> populate I think the above is not safe.
So either I can add scanning the PCI bus (which wouldn't be too
hard IMO), or we require Xen tools to add memory map entries with
"Reserved" attribute for passed-through PCI device's MMIO-areas
(we can still do that as PCI pass-through for PVH isn't possible
yet AFAIK).
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-29 14:19 ` [Xen-devel] " Juergen Gross
(?)
@ 2018-10-30 11:23 ` Roger Pau Monné
2018-10-30 12:12 ` Juergen Gross
2018-10-30 12:12 ` [Xen-devel] " Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-30 11:23 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On Mon, Oct 29, 2018 at 03:19:34PM +0100, Juergen Gross wrote:
> On 29/10/2018 13:57, Roger Pau Monné wrote:
> > On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
> >> On 19/10/2018 18:10, Roger Pau Monné wrote:
> >>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> >>>> Initialize the needed Xen specific data. This is:
> >>>>
> >>>> - the Xen start of day page containing the console and Xenstore ring
> >>>> page PFN and event channel
> >>>> - the grant table
> >>>> - the shared info page
> >>>>
> >>>> Set the RSDP address for the guest from the start_info page passed
> >>>> as boot parameter.
> >>>>
> >>>> Signed-off-by: Juergen Gross <jgross@suse.com>
> >>>> ---
> >>>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> >>>> 1 file changed, 107 insertions(+)
> >>>>
> >>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >>>> index b4933b454..93ed68245 100644
> >>>> --- a/grub-core/kern/i386/xen/pvh.c
> >>>> +++ b/grub-core/kern/i386/xen/pvh.c
> >>>> @@ -24,6 +24,7 @@
> >>>> #include <grub/xen.h>
> >>>> #include <grub/i386/linux.h>
> >>>> #include <grub/machine/kernel.h>
> >>>> +#include <xen/hvm/params.h>
> >>>> #include <xen/memory.h>
> >>>>
> >>>> struct xen_machine_mmap_entry
> >>>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> >>>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> >>>>
> >>>> static grub_uint32_t xen_cpuid_base;
> >>>> +static struct start_info grub_xen_start_page;
> >>>> static struct xen_machine_mmap_entry map[128];
> >>>> static unsigned int nr_map_entries;
> >>>>
> >>>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> >>>> return __res;
> >>>> }
> >>>>
> >>>> +static grub_uint32_t
> >>>> +grub_xen_get_param (int idx)
> >>>> +{
> >>>> + struct xen_hvm_param xhv;
> >>>> + int r;
> >>>> +
> >>>> + xhv.domid = DOMID_SELF;
> >>>> + xhv.index = idx;
> >>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> >>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> >>>> + if (r < 0)
> >>>> + grub_xen_early_halt ();
> >>>> + return xhv.value;
> >>>> +}
> >>>> +
> >>>> +static void *
> >>>> +grub_xen_add_physmap (unsigned int space, void *addr)
> >>>> +{
> >>>> + struct xen_add_to_physmap xatp;
> >>>> +
> >>>> + xatp.domid = DOMID_SELF;
> >>>> + xatp.idx = 0;
> >>>> + xatp.space = space;
> >>>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> >>>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> >>>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> >>>> + grub_xen_early_halt ();
> >>>> + return addr;
> >>>> +}
> >>>> +
> >>>> static void
> >>>> grub_xen_sort_mmap (void)
> >>>> {
> >>>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> >>>> grub_xen_sort_mmap ();
> >>>> }
> >>>>
> >>>> +static grub_uint64_t
> >>>> +grub_xen_find_page (grub_uint64_t start)
> >>>> +{
> >>>> + unsigned int i, j;
> >>>> + grub_uint64_t last = start;
> >>>> +
> >>>> + /* Try to find a e820 map hole below 4G. */
> >>>
> >>> Doing this is kind of dangerous, what if you end up placing something
> >>> on top of an MMIO region (either emulated or from a real passthrough
> >>> device)?
> >>
> >> Shouldn't those be marked as "Reserved" in the memory map?
> >
> > I don't think BARs are guaranteed to be in areas marked as reserved in
> > the memory map. Unless you also scan for PCI devices and make sure
> > there's no device with a BAR in the area you are attempting to
> > populate I think the above is not safe.
>
> So either I can add scanning the PCI bus (which wouldn't be too
> hard IMO), or we require Xen tools to add memory map entries with
> "Reserved" attribute for passed-through PCI device's MMIO-areas
> (we can still do that as PCI pass-through for PVH isn't possible
> yet AFAIK).
Ideally (and that's kind of far away from what we are now), I would
like to have an interface to request Xen for a range of gfns available
to map stuff in them (grants/foreign mappings/shared page...). That
interface could be a simple hypercall that would return such range, or
an hypercall that could be used to fetch something akin to an
'extended memory map' with specific Xen information (like such
regions).
In both cases this requires Xen having a clearer picture of the p2m,
because any of the above solutions cannot rely on scanning the p2m
table in order to figure out what's where.
So the only change I would request is that if you use a RAM page you
update the memory map stored in Xen to match the new layout, by using
the XENMEM_set_memory_map hypercall.
Thanks, Roger.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-30 11:23 ` Roger Pau Monné
@ 2018-10-30 12:12 ` Juergen Gross
2018-10-30 12:12 ` [Xen-devel] " Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-30 12:12 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On 30/10/2018 12:23, Roger Pau Monné wrote:
> On Mon, Oct 29, 2018 at 03:19:34PM +0100, Juergen Gross wrote:
>> On 29/10/2018 13:57, Roger Pau Monné wrote:
>>> On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
>>>> On 19/10/2018 18:10, Roger Pau Monné wrote:
>>>>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>>>>>> Initialize the needed Xen specific data. This is:
>>>>>>
>>>>>> - the Xen start of day page containing the console and Xenstore ring
>>>>>> page PFN and event channel
>>>>>> - the grant table
>>>>>> - the shared info page
>>>>>>
>>>>>> Set the RSDP address for the guest from the start_info page passed
>>>>>> as boot parameter.
>>>>>>
>>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>>>> ---
>>>>>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 107 insertions(+)
>>>>>>
>>>>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>>>>>> index b4933b454..93ed68245 100644
>>>>>> --- a/grub-core/kern/i386/xen/pvh.c
>>>>>> +++ b/grub-core/kern/i386/xen/pvh.c
>>>>>> @@ -24,6 +24,7 @@
>>>>>> #include <grub/xen.h>
>>>>>> #include <grub/i386/linux.h>
>>>>>> #include <grub/machine/kernel.h>
>>>>>> +#include <xen/hvm/params.h>
>>>>>> #include <xen/memory.h>
>>>>>>
>>>>>> struct xen_machine_mmap_entry
>>>>>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>>>>>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>>>>>
>>>>>> static grub_uint32_t xen_cpuid_base;
>>>>>> +static struct start_info grub_xen_start_page;
>>>>>> static struct xen_machine_mmap_entry map[128];
>>>>>> static unsigned int nr_map_entries;
>>>>>>
>>>>>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>>>>>> return __res;
>>>>>> }
>>>>>>
>>>>>> +static grub_uint32_t
>>>>>> +grub_xen_get_param (int idx)
>>>>>> +{
>>>>>> + struct xen_hvm_param xhv;
>>>>>> + int r;
>>>>>> +
>>>>>> + xhv.domid = DOMID_SELF;
>>>>>> + xhv.index = idx;
>>>>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>>>>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>>>>>> + if (r < 0)
>>>>>> + grub_xen_early_halt ();
>>>>>> + return xhv.value;
>>>>>> +}
>>>>>> +
>>>>>> +static void *
>>>>>> +grub_xen_add_physmap (unsigned int space, void *addr)
>>>>>> +{
>>>>>> + struct xen_add_to_physmap xatp;
>>>>>> +
>>>>>> + xatp.domid = DOMID_SELF;
>>>>>> + xatp.idx = 0;
>>>>>> + xatp.space = space;
>>>>>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>>>>>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>>>>>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>>>>>> + grub_xen_early_halt ();
>>>>>> + return addr;
>>>>>> +}
>>>>>> +
>>>>>> static void
>>>>>> grub_xen_sort_mmap (void)
>>>>>> {
>>>>>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>>>>>> grub_xen_sort_mmap ();
>>>>>> }
>>>>>>
>>>>>> +static grub_uint64_t
>>>>>> +grub_xen_find_page (grub_uint64_t start)
>>>>>> +{
>>>>>> + unsigned int i, j;
>>>>>> + grub_uint64_t last = start;
>>>>>> +
>>>>>> + /* Try to find a e820 map hole below 4G. */
>>>>>
>>>>> Doing this is kind of dangerous, what if you end up placing something
>>>>> on top of an MMIO region (either emulated or from a real passthrough
>>>>> device)?
>>>>
>>>> Shouldn't those be marked as "Reserved" in the memory map?
>>>
>>> I don't think BARs are guaranteed to be in areas marked as reserved in
>>> the memory map. Unless you also scan for PCI devices and make sure
>>> there's no device with a BAR in the area you are attempting to
>>> populate I think the above is not safe.
>>
>> So either I can add scanning the PCI bus (which wouldn't be too
>> hard IMO), or we require Xen tools to add memory map entries with
>> "Reserved" attribute for passed-through PCI device's MMIO-areas
>> (we can still do that as PCI pass-through for PVH isn't possible
>> yet AFAIK).
>
> Ideally (and that's kind of far away from what we are now), I would
> like to have an interface to request Xen for a range of gfns available
> to map stuff in them (grants/foreign mappings/shared page...). That
> interface could be a simple hypercall that would return such range, or
> an hypercall that could be used to fetch something akin to an
> 'extended memory map' with specific Xen information (like such
> regions).
>
> In both cases this requires Xen having a clearer picture of the p2m,
> because any of the above solutions cannot rely on scanning the p2m
> table in order to figure out what's where.
>
> So the only change I would request is that if you use a RAM page you
> update the memory map stored in Xen to match the new layout, by using
> the XENMEM_set_memory_map hypercall.
Okay, this is simple.
Nevertheless I'm adding the already finished patch for scanning the
PCI devices to find MMIO areas.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-30 11:23 ` Roger Pau Monné
2018-10-30 12:12 ` Juergen Gross
@ 2018-10-30 12:12 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-30 12:12 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: grub-devel, hans, phcoder, daniel.kiper, xen-devel
On 30/10/2018 12:23, Roger Pau Monné wrote:
> On Mon, Oct 29, 2018 at 03:19:34PM +0100, Juergen Gross wrote:
>> On 29/10/2018 13:57, Roger Pau Monné wrote:
>>> On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
>>>> On 19/10/2018 18:10, Roger Pau Monné wrote:
>>>>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>>>>>> Initialize the needed Xen specific data. This is:
>>>>>>
>>>>>> - the Xen start of day page containing the console and Xenstore ring
>>>>>> page PFN and event channel
>>>>>> - the grant table
>>>>>> - the shared info page
>>>>>>
>>>>>> Set the RSDP address for the guest from the start_info page passed
>>>>>> as boot parameter.
>>>>>>
>>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>>>> ---
>>>>>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 107 insertions(+)
>>>>>>
>>>>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>>>>>> index b4933b454..93ed68245 100644
>>>>>> --- a/grub-core/kern/i386/xen/pvh.c
>>>>>> +++ b/grub-core/kern/i386/xen/pvh.c
>>>>>> @@ -24,6 +24,7 @@
>>>>>> #include <grub/xen.h>
>>>>>> #include <grub/i386/linux.h>
>>>>>> #include <grub/machine/kernel.h>
>>>>>> +#include <xen/hvm/params.h>
>>>>>> #include <xen/memory.h>
>>>>>>
>>>>>> struct xen_machine_mmap_entry
>>>>>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>>>>>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>>>>>
>>>>>> static grub_uint32_t xen_cpuid_base;
>>>>>> +static struct start_info grub_xen_start_page;
>>>>>> static struct xen_machine_mmap_entry map[128];
>>>>>> static unsigned int nr_map_entries;
>>>>>>
>>>>>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
>>>>>> return __res;
>>>>>> }
>>>>>>
>>>>>> +static grub_uint32_t
>>>>>> +grub_xen_get_param (int idx)
>>>>>> +{
>>>>>> + struct xen_hvm_param xhv;
>>>>>> + int r;
>>>>>> +
>>>>>> + xhv.domid = DOMID_SELF;
>>>>>> + xhv.index = idx;
>>>>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>>>>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>>>>>> + if (r < 0)
>>>>>> + grub_xen_early_halt ();
>>>>>> + return xhv.value;
>>>>>> +}
>>>>>> +
>>>>>> +static void *
>>>>>> +grub_xen_add_physmap (unsigned int space, void *addr)
>>>>>> +{
>>>>>> + struct xen_add_to_physmap xatp;
>>>>>> +
>>>>>> + xatp.domid = DOMID_SELF;
>>>>>> + xatp.idx = 0;
>>>>>> + xatp.space = space;
>>>>>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>>>>>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>>>>>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>>>>>> + grub_xen_early_halt ();
>>>>>> + return addr;
>>>>>> +}
>>>>>> +
>>>>>> static void
>>>>>> grub_xen_sort_mmap (void)
>>>>>> {
>>>>>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>>>>>> grub_xen_sort_mmap ();
>>>>>> }
>>>>>>
>>>>>> +static grub_uint64_t
>>>>>> +grub_xen_find_page (grub_uint64_t start)
>>>>>> +{
>>>>>> + unsigned int i, j;
>>>>>> + grub_uint64_t last = start;
>>>>>> +
>>>>>> + /* Try to find a e820 map hole below 4G. */
>>>>>
>>>>> Doing this is kind of dangerous, what if you end up placing something
>>>>> on top of an MMIO region (either emulated or from a real passthrough
>>>>> device)?
>>>>
>>>> Shouldn't those be marked as "Reserved" in the memory map?
>>>
>>> I don't think BARs are guaranteed to be in areas marked as reserved in
>>> the memory map. Unless you also scan for PCI devices and make sure
>>> there's no device with a BAR in the area you are attempting to
>>> populate I think the above is not safe.
>>
>> So either I can add scanning the PCI bus (which wouldn't be too
>> hard IMO), or we require Xen tools to add memory map entries with
>> "Reserved" attribute for passed-through PCI device's MMIO-areas
>> (we can still do that as PCI pass-through for PVH isn't possible
>> yet AFAIK).
>
> Ideally (and that's kind of far away from what we are now), I would
> like to have an interface to request Xen for a range of gfns available
> to map stuff in them (grants/foreign mappings/shared page...). That
> interface could be a simple hypercall that would return such range, or
> an hypercall that could be used to fetch something akin to an
> 'extended memory map' with specific Xen information (like such
> regions).
>
> In both cases this requires Xen having a clearer picture of the p2m,
> because any of the above solutions cannot rely on scanning the p2m
> table in order to figure out what's where.
>
> So the only change I would request is that if you use a RAM page you
> update the memory map stored in Xen to match the new layout, by using
> the XENMEM_set_memory_map hypercall.
Okay, this is simple.
Nevertheless I'm adding the already finished patch for scanning the
PCI devices to find MMIO areas.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 12/18] xen: setup Xen specific data for PVH
2018-10-29 14:19 ` [Xen-devel] " Juergen Gross
(?)
(?)
@ 2018-10-30 11:23 ` Roger Pau Monné
-1 siblings, 0 replies; 148+ messages in thread
From: Roger Pau Monné @ 2018-10-30 11:23 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, daniel.kiper, xen-devel, phcoder
On Mon, Oct 29, 2018 at 03:19:34PM +0100, Juergen Gross wrote:
> On 29/10/2018 13:57, Roger Pau Monné wrote:
> > On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
> >> On 19/10/2018 18:10, Roger Pau Monné wrote:
> >>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> >>>> Initialize the needed Xen specific data. This is:
> >>>>
> >>>> - the Xen start of day page containing the console and Xenstore ring
> >>>> page PFN and event channel
> >>>> - the grant table
> >>>> - the shared info page
> >>>>
> >>>> Set the RSDP address for the guest from the start_info page passed
> >>>> as boot parameter.
> >>>>
> >>>> Signed-off-by: Juergen Gross <jgross@suse.com>
> >>>> ---
> >>>> grub-core/kern/i386/xen/pvh.c | 107 ++++++++++++++++++++++++++++++++++++++++++
> >>>> 1 file changed, 107 insertions(+)
> >>>>
> >>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >>>> index b4933b454..93ed68245 100644
> >>>> --- a/grub-core/kern/i386/xen/pvh.c
> >>>> +++ b/grub-core/kern/i386/xen/pvh.c
> >>>> @@ -24,6 +24,7 @@
> >>>> #include <grub/xen.h>
> >>>> #include <grub/i386/linux.h>
> >>>> #include <grub/machine/kernel.h>
> >>>> +#include <xen/hvm/params.h>
> >>>> #include <xen/memory.h>
> >>>>
> >>>> struct xen_machine_mmap_entry
> >>>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> >>>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> >>>>
> >>>> static grub_uint32_t xen_cpuid_base;
> >>>> +static struct start_info grub_xen_start_page;
> >>>> static struct xen_machine_mmap_entry map[128];
> >>>> static unsigned int nr_map_entries;
> >>>>
> >>>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, grub_uint32_t a0,
> >>>> return __res;
> >>>> }
> >>>>
> >>>> +static grub_uint32_t
> >>>> +grub_xen_get_param (int idx)
> >>>> +{
> >>>> + struct xen_hvm_param xhv;
> >>>> + int r;
> >>>> +
> >>>> + xhv.domid = DOMID_SELF;
> >>>> + xhv.index = idx;
> >>>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> >>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> >>>> + if (r < 0)
> >>>> + grub_xen_early_halt ();
> >>>> + return xhv.value;
> >>>> +}
> >>>> +
> >>>> +static void *
> >>>> +grub_xen_add_physmap (unsigned int space, void *addr)
> >>>> +{
> >>>> + struct xen_add_to_physmap xatp;
> >>>> +
> >>>> + xatp.domid = DOMID_SELF;
> >>>> + xatp.idx = 0;
> >>>> + xatp.space = space;
> >>>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> >>>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> >>>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> >>>> + grub_xen_early_halt ();
> >>>> + return addr;
> >>>> +}
> >>>> +
> >>>> static void
> >>>> grub_xen_sort_mmap (void)
> >>>> {
> >>>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> >>>> grub_xen_sort_mmap ();
> >>>> }
> >>>>
> >>>> +static grub_uint64_t
> >>>> +grub_xen_find_page (grub_uint64_t start)
> >>>> +{
> >>>> + unsigned int i, j;
> >>>> + grub_uint64_t last = start;
> >>>> +
> >>>> + /* Try to find a e820 map hole below 4G. */
> >>>
> >>> Doing this is kind of dangerous, what if you end up placing something
> >>> on top of an MMIO region (either emulated or from a real passthrough
> >>> device)?
> >>
> >> Shouldn't those be marked as "Reserved" in the memory map?
> >
> > I don't think BARs are guaranteed to be in areas marked as reserved in
> > the memory map. Unless you also scan for PCI devices and make sure
> > there's no device with a BAR in the area you are attempting to
> > populate I think the above is not safe.
>
> So either I can add scanning the PCI bus (which wouldn't be too
> hard IMO), or we require Xen tools to add memory map entries with
> "Reserved" attribute for passed-through PCI device's MMIO-areas
> (we can still do that as PCI pass-through for PVH isn't possible
> yet AFAIK).
Ideally (and that's kind of far away from what we are now), I would
like to have an interface to request Xen for a range of gfns available
to map stuff in them (grants/foreign mappings/shared page...). That
interface could be a simple hypercall that would return such range, or
an hypercall that could be used to fetch something akin to an
'extended memory map' with specific Xen information (like such
regions).
In both cases this requires Xen having a clearer picture of the p2m,
because any of the above solutions cannot rely on scanning the p2m
table in order to figure out what's where.
So the only change I would request is that if you use a RAM page you
update the memory map stored in Xen to match the new layout, by using
the XENMEM_set_memory_map hypercall.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 13/18] xen: init memory regions for PVH
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Add all usable memory regions to grub memory management and add the
needed mmap iterate code.
As we are running in 32-bit mode don't add memory above 4GB.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index 93ed68245..c4a8bccf4 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
grub_xen_sort_mmap ();
}
+static void
+grub_xen_mm_init_regions (void)
+{
+ grub_uint64_t modend, from, to;
+ unsigned int i;
+
+ modend = grub_modules_get_end ();
+
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (map[i].type != GRUB_MEMORY_AVAILABLE)
+ continue;
+ from = map[i].addr;
+ to = from + map[i].len;
+ if (from < modend)
+ from = modend;
+ if (from >= to || from >= 0x100000000ULL)
+ continue;
+ if (to > 0x100000000ULL)
+ to = 0x100000000ULL;
+ grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
+ }
+}
+
static grub_uint64_t
grub_xen_find_page (grub_uint64_t start)
{
@@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
(void *) par);
+ grub_xen_mm_init_regions ();
+
grub_rsdp_addr = pvh_start_info->rsdp_paddr;
}
grub_err_t
grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
{
+ unsigned int i;
+
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, hook_data))
+ break;
+ }
+
+ return GRUB_ERR_NONE;
}
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 13/18] xen: init memory regions for PVH
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Add all usable memory regions to grub memory management and add the
needed mmap iterate code.
As we are running in 32-bit mode don't add memory above 4GB.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
grub-core/kern/i386/xen/pvh.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index 93ed68245..c4a8bccf4 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
grub_xen_sort_mmap ();
}
+static void
+grub_xen_mm_init_regions (void)
+{
+ grub_uint64_t modend, from, to;
+ unsigned int i;
+
+ modend = grub_modules_get_end ();
+
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (map[i].type != GRUB_MEMORY_AVAILABLE)
+ continue;
+ from = map[i].addr;
+ to = from + map[i].len;
+ if (from < modend)
+ from = modend;
+ if (from >= to || from >= 0x100000000ULL)
+ continue;
+ if (to > 0x100000000ULL)
+ to = 0x100000000ULL;
+ grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
+ }
+}
+
static grub_uint64_t
grub_xen_find_page (grub_uint64_t start)
{
@@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
(void *) par);
+ grub_xen_mm_init_regions ();
+
grub_rsdp_addr = pvh_start_info->rsdp_paddr;
}
grub_err_t
grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
{
+ unsigned int i;
+
+ for (i = 0; i < nr_map_entries; i++)
+ {
+ if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, hook_data))
+ break;
+ }
+
+ return GRUB_ERR_NONE;
}
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 13/18] xen: init memory regions for PVH
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-22 11:31 ` Daniel Kiper
2018-10-22 11:43 ` Juergen Gross
2018-10-22 11:43 ` Juergen Gross
-1 siblings, 2 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:31 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
> Add all usable memory regions to grub memory management and add the
> needed mmap iterate code.
I am missing a few words why this patch is needed. Especially why
grub_machine_mmap_iterate() has to belong to this patch. However,
I think that it should be introduced by patch in which
grub_machine_mmap_iterate() is used at some point.
> As we are running in 32-bit mode don't add memory above 4GB.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index 93ed68245..c4a8bccf4 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
> grub_xen_sort_mmap ();
> }
>
> +static void
> +grub_xen_mm_init_regions (void)
> +{
> + grub_uint64_t modend, from, to;
> + unsigned int i;
> +
> + modend = grub_modules_get_end ();
> +
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (map[i].type != GRUB_MEMORY_AVAILABLE)
> + continue;
> + from = map[i].addr;
> + to = from + map[i].len;
> + if (from < modend)
> + from = modend;
> + if (from >= to || from >= 0x100000000ULL)
> + continue;
> + if (to > 0x100000000ULL)
> + to = 0x100000000ULL;
> + grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
> + }
> +}
> +
> static grub_uint64_t
> grub_xen_find_page (grub_uint64_t start)
> {
> @@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
> grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
> (void *) par);
>
> + grub_xen_mm_init_regions ();
> +
> grub_rsdp_addr = pvh_start_info->rsdp_paddr;
> }
>
> grub_err_t
> grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
> {
> + unsigned int i;
> +
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, hook_data))
> + break;
> + }
> +
> + return GRUB_ERR_NONE;
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 13/18] xen: init memory regions for PVH
2018-10-22 11:31 ` Daniel Kiper
@ 2018-10-22 11:43 ` Juergen Gross
2018-10-22 12:08 ` Daniel Kiper
2018-10-22 12:08 ` Daniel Kiper
2018-10-22 11:43 ` Juergen Gross
1 sibling, 2 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-22 11:43 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, xen-devel, phcoder, hans
On 22/10/2018 13:31, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
>> Add all usable memory regions to grub memory management and add the
>> needed mmap iterate code.
>
> I am missing a few words why this patch is needed. Especially why
> grub_machine_mmap_iterate() has to belong to this patch. However,
> I think that it should be introduced by patch in which
> grub_machine_mmap_iterate() is used at some point.
That would again lead to one giant PVH patch which you didn't like.
grub_machine_mmap_iterate() is being used by grub common code like
grub-core/lib/relocator.c or grub-core/mmap/mmap.c
grub_machine_mmap_iterate() belongs into this patch as it is the
main user of the memory map introduced here.
Juergen
>
>> As we are running in 32-bit mode don't add memory above 4GB.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index 93ed68245..c4a8bccf4 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
>> grub_xen_sort_mmap ();
>> }
>>
>> +static void
>> +grub_xen_mm_init_regions (void)
>> +{
>> + grub_uint64_t modend, from, to;
>> + unsigned int i;
>> +
>> + modend = grub_modules_get_end ();
>> +
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (map[i].type != GRUB_MEMORY_AVAILABLE)
>> + continue;
>> + from = map[i].addr;
>> + to = from + map[i].len;
>> + if (from < modend)
>> + from = modend;
>> + if (from >= to || from >= 0x100000000ULL)
>> + continue;
>> + if (to > 0x100000000ULL)
>> + to = 0x100000000ULL;
>> + grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
>> + }
>> +}
>> +
>> static grub_uint64_t
>> grub_xen_find_page (grub_uint64_t start)
>> {
>> @@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
>> grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
>> (void *) par);
>>
>> + grub_xen_mm_init_regions ();
>> +
>> grub_rsdp_addr = pvh_start_info->rsdp_paddr;
>> }
>>
>> grub_err_t
>> grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
>> {
>> + unsigned int i;
>> +
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, hook_data))
>> + break;
>> + }
>> +
>> + return GRUB_ERR_NONE;
>
> Daniel
>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 13/18] xen: init memory regions for PVH
2018-10-22 11:43 ` Juergen Gross
@ 2018-10-22 12:08 ` Daniel Kiper
2018-10-22 12:08 ` Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 12:08 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Mon, Oct 22, 2018 at 01:43:53PM +0200, Juergen Gross wrote:
> On 22/10/2018 13:31, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
> >> Add all usable memory regions to grub memory management and add the
> >> needed mmap iterate code.
> >
> > I am missing a few words why this patch is needed. Especially why
> > grub_machine_mmap_iterate() has to belong to this patch. However,
> > I think that it should be introduced by patch in which
> > grub_machine_mmap_iterate() is used at some point.
>
> That would again lead to one giant PVH patch which you didn't like.
>
> grub_machine_mmap_iterate() is being used by grub common code like
> grub-core/lib/relocator.c or grub-core/mmap/mmap.c
>
> grub_machine_mmap_iterate() belongs into this patch as it is the
> main user of the memory map introduced here.
OK, let's leave it here. Though commit message has to be updated accordingly.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 13/18] xen: init memory regions for PVH
2018-10-22 11:43 ` Juergen Gross
2018-10-22 12:08 ` Daniel Kiper
@ 2018-10-22 12:08 ` Daniel Kiper
1 sibling, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 12:08 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Mon, Oct 22, 2018 at 01:43:53PM +0200, Juergen Gross wrote:
> On 22/10/2018 13:31, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
> >> Add all usable memory regions to grub memory management and add the
> >> needed mmap iterate code.
> >
> > I am missing a few words why this patch is needed. Especially why
> > grub_machine_mmap_iterate() has to belong to this patch. However,
> > I think that it should be introduced by patch in which
> > grub_machine_mmap_iterate() is used at some point.
>
> That would again lead to one giant PVH patch which you didn't like.
>
> grub_machine_mmap_iterate() is being used by grub common code like
> grub-core/lib/relocator.c or grub-core/mmap/mmap.c
>
> grub_machine_mmap_iterate() belongs into this patch as it is the
> main user of the memory map introduced here.
OK, let's leave it here. Though commit message has to be updated accordingly.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 13/18] xen: init memory regions for PVH
2018-10-22 11:31 ` Daniel Kiper
2018-10-22 11:43 ` Juergen Gross
@ 2018-10-22 11:43 ` Juergen Gross
1 sibling, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-22 11:43 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 22/10/2018 13:31, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
>> Add all usable memory regions to grub memory management and add the
>> needed mmap iterate code.
>
> I am missing a few words why this patch is needed. Especially why
> grub_machine_mmap_iterate() has to belong to this patch. However,
> I think that it should be introduced by patch in which
> grub_machine_mmap_iterate() is used at some point.
That would again lead to one giant PVH patch which you didn't like.
grub_machine_mmap_iterate() is being used by grub common code like
grub-core/lib/relocator.c or grub-core/mmap/mmap.c
grub_machine_mmap_iterate() belongs into this patch as it is the
main user of the memory map introduced here.
Juergen
>
>> As we are running in 32-bit mode don't add memory above 4GB.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> grub-core/kern/i386/xen/pvh.c | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index 93ed68245..c4a8bccf4 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
>> grub_xen_sort_mmap ();
>> }
>>
>> +static void
>> +grub_xen_mm_init_regions (void)
>> +{
>> + grub_uint64_t modend, from, to;
>> + unsigned int i;
>> +
>> + modend = grub_modules_get_end ();
>> +
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (map[i].type != GRUB_MEMORY_AVAILABLE)
>> + continue;
>> + from = map[i].addr;
>> + to = from + map[i].len;
>> + if (from < modend)
>> + from = modend;
>> + if (from >= to || from >= 0x100000000ULL)
>> + continue;
>> + if (to > 0x100000000ULL)
>> + to = 0x100000000ULL;
>> + grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
>> + }
>> +}
>> +
>> static grub_uint64_t
>> grub_xen_find_page (grub_uint64_t start)
>> {
>> @@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
>> grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
>> (void *) par);
>>
>> + grub_xen_mm_init_regions ();
>> +
>> grub_rsdp_addr = pvh_start_info->rsdp_paddr;
>> }
>>
>> grub_err_t
>> grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
>> {
>> + unsigned int i;
>> +
>> + for (i = 0; i < nr_map_entries; i++)
>> + {
>> + if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, hook_data))
>> + break;
>> + }
>> +
>> + return GRUB_ERR_NONE;
>
> Daniel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 13/18] xen: init memory regions for PVH
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-22 11:31 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:31 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
> Add all usable memory regions to grub memory management and add the
> needed mmap iterate code.
I am missing a few words why this patch is needed. Especially why
grub_machine_mmap_iterate() has to belong to this patch. However,
I think that it should be introduced by patch in which
grub_machine_mmap_iterate() is used at some point.
> As we are running in 32-bit mode don't add memory above 4GB.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> grub-core/kern/i386/xen/pvh.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index 93ed68245..c4a8bccf4 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
> grub_xen_sort_mmap ();
> }
>
> +static void
> +grub_xen_mm_init_regions (void)
> +{
> + grub_uint64_t modend, from, to;
> + unsigned int i;
> +
> + modend = grub_modules_get_end ();
> +
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (map[i].type != GRUB_MEMORY_AVAILABLE)
> + continue;
> + from = map[i].addr;
> + to = from + map[i].len;
> + if (from < modend)
> + from = modend;
> + if (from >= to || from >= 0x100000000ULL)
> + continue;
> + if (to > 0x100000000ULL)
> + to = 0x100000000ULL;
> + grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
> + }
> +}
> +
> static grub_uint64_t
> grub_xen_find_page (grub_uint64_t start)
> {
> @@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
> grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
> (void *) par);
>
> + grub_xen_mm_init_regions ();
> +
> grub_rsdp_addr = pvh_start_info->rsdp_paddr;
> }
>
> grub_err_t
> grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
> {
> + unsigned int i;
> +
> + for (i = 0; i < nr_map_entries; i++)
> + {
> + if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, hook_data))
> + break;
> + }
> +
> + return GRUB_ERR_NONE;
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 14/18] xenpvh: add build runes for grub-core
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Add the modifications to the build system needed to build a xenpvh
grub.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
gentpl.py | 4 ++--
grub-core/Makefile.am | 12 ++++++++++++
grub-core/Makefile.core.def | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/gentpl.py b/gentpl.py
index da67965a4..9732b4aee 100644
--- a/gentpl.py
+++ b/gentpl.py
@@ -28,7 +28,7 @@ import re
GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
"i386_multiboot", "i386_ieee1275", "x86_64_efi",
- "i386_xen", "x86_64_xen",
+ "i386_xen", "x86_64_xen", "i386_xenpvh",
"mips_loongson", "sparc64_ieee1275",
"powerpc_ieee1275", "mips_arc", "ia64_efi",
"mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
@@ -71,7 +71,7 @@ GROUPS["videomodules"] = GRUB_PLATFORMS[:];
for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
# Similar for terminfo
-GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
+GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
GROUPS["terminfomodule"] = GRUB_PLATFORMS[:];
for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
index f4ff62b76..d4417e2c4 100644
--- a/grub-core/Makefile.am
+++ b/grub-core/Makefile.am
@@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
endif
+if COND_i386_xenpvh
+KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
+KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
+endif
+
if COND_i386_efi
KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 9590e87d9..c42cebc38 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -79,6 +79,8 @@ kernel = {
i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
x86_64_xen_ldflags = '$(TARGET_IMG_LDFLAGS)';
x86_64_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
+ i386_xenpvh_ldflags = '$(TARGET_IMG_LDFLAGS)';
+ i386_xenpvh_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x100000';
mips_loongson_ldflags = '-Wl,-Ttext,0x80200000';
powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000';
@@ -100,6 +102,7 @@ kernel = {
x86_64_efi_startup = kern/x86_64/efi/startup.S;
i386_xen_startup = kern/i386/xen/startup.S;
x86_64_xen_startup = kern/x86_64/xen/startup.S;
+ i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
i386_qemu_startup = kern/i386/qemu/startup.S;
i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
i386_coreboot_startup = kern/i386/coreboot/startup.S;
@@ -177,6 +180,7 @@ kernel = {
i386 = kern/i386/dl.c;
i386_xen = kern/i386/dl.c;
+ i386_xenpvh = kern/i386/dl.c;
i386_coreboot = kern/i386/coreboot/init.c;
i386_multiboot = kern/i386/coreboot/init.c;
@@ -222,6 +226,14 @@ kernel = {
xen = disk/xen/xendisk.c;
xen = commands/boot.c;
+ i386_xenpvh = kern/i386/tsc.c;
+ i386_xenpvh = kern/i386/xen/tsc.c;
+ i386_xenpvh = commands/boot.c;
+ i386_xenpvh = kern/xen/init.c;
+ i386_xenpvh = kern/i386/xen/pvh.c;
+ i386_xenpvh = term/xen/console.c;
+ i386_xenpvh = disk/xen/xendisk.c;
+
ia64_efi = kern/ia64/efi/startup.S;
ia64_efi = kern/ia64/efi/init.c;
ia64_efi = kern/ia64/dl.c;
@@ -801,6 +813,7 @@ module = {
name = cpuid;
common = commands/i386/cpuid.c;
enable = x86;
+ enable = i386_xenpvh;
enable = i386_xen;
enable = x86_64_xen;
};
@@ -860,6 +873,7 @@ module = {
i386_coreboot = lib/i386/halt.c;
i386_qemu = lib/i386/halt.c;
xen = lib/xen/halt.c;
+ i386_xenpvh = lib/xen/halt.c;
efi = lib/efi/halt.c;
ieee1275 = lib/ieee1275/halt.c;
emu = lib/emu/halt.c;
@@ -877,6 +891,7 @@ module = {
mips_loongson = lib/mips/loongson/reboot.c;
mips_qemu_mips = lib/mips/qemu_mips/reboot.c;
xen = lib/xen/reboot.c;
+ i386_xenpvh = lib/xen/reboot.c;
uboot = lib/uboot/reboot.c;
arm_coreboot = lib/dummy/reboot.c;
common = commands/reboot.c;
@@ -1545,12 +1560,18 @@ module = {
x86 = lib/i386/relocator16.S;
x86 = lib/i386/relocator32.S;
x86 = lib/i386/relocator64.S;
+ i386_xenpvh = lib/i386/relocator16.S;
+ i386_xenpvh = lib/i386/relocator32.S;
+ i386_xenpvh = lib/i386/relocator64.S;
i386 = lib/i386/relocator_asm.S;
+ i386_xenpvh = lib/i386/relocator_asm.S;
x86_64 = lib/x86_64/relocator_asm.S;
i386_xen = lib/i386/relocator_asm.S;
x86_64_xen = lib/x86_64/relocator_asm.S;
x86 = lib/i386/relocator.c;
x86 = lib/i386/relocator_common_c.c;
+ i386_xenpvh = lib/i386/relocator.c;
+ i386_xenpvh = lib/i386/relocator_common_c.c;
ieee1275 = lib/ieee1275/relocator.c;
efi = lib/efi/relocator.c;
mips = lib/mips/relocator_asm.S;
@@ -1569,6 +1590,7 @@ module = {
enable = mips;
enable = powerpc;
enable = x86;
+ enable = i386_xenpvh;
enable = xen;
};
@@ -1583,6 +1605,7 @@ module = {
sparc64_ieee1275 = lib/ieee1275/cmos.c;
powerpc_ieee1275 = lib/ieee1275/cmos.c;
xen = lib/xen/datetime.c;
+ i386_xenpvh = lib/xen/datetime.c;
mips_arc = lib/arc/datetime.c;
enable = noemu;
@@ -1666,6 +1689,7 @@ module = {
common = loader/multiboot.c;
common = loader/multiboot_mbi2.c;
enable = x86;
+ enable = i386_xenpvh;
enable = mips;
};
@@ -1673,8 +1697,10 @@ module = {
name = multiboot;
common = loader/multiboot.c;
x86 = loader/i386/multiboot_mbi.c;
+ i386_xenpvh = loader/i386/multiboot_mbi.c;
extra_dist = loader/multiboot_elfxx.c;
enable = x86;
+ enable = i386_xenpvh;
};
module = {
@@ -1686,8 +1712,10 @@ module = {
module = {
name = linux;
x86 = loader/i386/linux.c;
+ i386_xenpvh = loader/i386/linux.c;
xen = loader/i386/xen.c;
i386_pc = lib/i386/pc/vesa_modes_table.c;
+ i386_xenpvh = lib/i386/pc/vesa_modes_table.c;
mips = loader/mips/linux.c;
powerpc_ieee1275 = loader/powerpc/ieee1275/linux.c;
sparc64_ieee1275 = loader/sparc64/ieee1275/linux.c;
@@ -1775,6 +1803,8 @@ module = {
common = mmap/mmap.c;
x86 = mmap/i386/uppermem.c;
x86 = mmap/i386/mmap.c;
+ i386_xenpvh = mmap/i386/uppermem.c;
+ i386_xenpvh = mmap/i386/mmap.c;
i386_pc = mmap/i386/pc/mmap.c;
i386_pc = mmap/i386/pc/mmap_helper.S;
@@ -1784,6 +1814,7 @@ module = {
mips = mmap/mips/uppermem.c;
enable = x86;
+ enable = i386_xenpvh;
enable = ia64_efi;
enable = arm_efi;
enable = arm64_efi;
@@ -2023,6 +2054,7 @@ module = {
name = legacy_password_test;
common = tests/legacy_password_test.c;
enable = i386_pc;
+ enable = i386_xenpvh;
enable = i386_efi;
enable = x86_64_efi;
enable = emu;
@@ -2221,6 +2253,7 @@ module = {
xen = lib/i386/pc/vesa_modes_table.c;
enable = i386_pc;
+ enable = i386_xenpvh;
enable = i386_efi;
enable = x86_64_efi;
enable = emu;
@@ -2264,10 +2297,12 @@ module = {
module = {
name = backtrace;
x86 = lib/i386/backtrace.c;
+ i386_xenpvh = lib/i386/backtrace.c;
i386_xen = lib/i386/backtrace.c;
x86_64_xen = lib/i386/backtrace.c;
common = lib/backtrace.c;
enable = x86;
+ enable = i386_xenpvh;
enable = i386_xen;
enable = x86_64_xen;
};
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 14/18] xenpvh: add build runes for grub-core
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Add the modifications to the build system needed to build a xenpvh
grub.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
gentpl.py | 4 ++--
grub-core/Makefile.am | 12 ++++++++++++
grub-core/Makefile.core.def | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/gentpl.py b/gentpl.py
index da67965a4..9732b4aee 100644
--- a/gentpl.py
+++ b/gentpl.py
@@ -28,7 +28,7 @@ import re
GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
"i386_multiboot", "i386_ieee1275", "x86_64_efi",
- "i386_xen", "x86_64_xen",
+ "i386_xen", "x86_64_xen", "i386_xenpvh",
"mips_loongson", "sparc64_ieee1275",
"powerpc_ieee1275", "mips_arc", "ia64_efi",
"mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
@@ -71,7 +71,7 @@ GROUPS["videomodules"] = GRUB_PLATFORMS[:];
for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
# Similar for terminfo
-GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
+GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
GROUPS["terminfomodule"] = GRUB_PLATFORMS[:];
for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
index f4ff62b76..d4417e2c4 100644
--- a/grub-core/Makefile.am
+++ b/grub-core/Makefile.am
@@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
endif
+if COND_i386_xenpvh
+KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
+KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
+KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
+endif
+
if COND_i386_efi
KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 9590e87d9..c42cebc38 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -79,6 +79,8 @@ kernel = {
i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
x86_64_xen_ldflags = '$(TARGET_IMG_LDFLAGS)';
x86_64_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
+ i386_xenpvh_ldflags = '$(TARGET_IMG_LDFLAGS)';
+ i386_xenpvh_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x100000';
mips_loongson_ldflags = '-Wl,-Ttext,0x80200000';
powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000';
@@ -100,6 +102,7 @@ kernel = {
x86_64_efi_startup = kern/x86_64/efi/startup.S;
i386_xen_startup = kern/i386/xen/startup.S;
x86_64_xen_startup = kern/x86_64/xen/startup.S;
+ i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
i386_qemu_startup = kern/i386/qemu/startup.S;
i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
i386_coreboot_startup = kern/i386/coreboot/startup.S;
@@ -177,6 +180,7 @@ kernel = {
i386 = kern/i386/dl.c;
i386_xen = kern/i386/dl.c;
+ i386_xenpvh = kern/i386/dl.c;
i386_coreboot = kern/i386/coreboot/init.c;
i386_multiboot = kern/i386/coreboot/init.c;
@@ -222,6 +226,14 @@ kernel = {
xen = disk/xen/xendisk.c;
xen = commands/boot.c;
+ i386_xenpvh = kern/i386/tsc.c;
+ i386_xenpvh = kern/i386/xen/tsc.c;
+ i386_xenpvh = commands/boot.c;
+ i386_xenpvh = kern/xen/init.c;
+ i386_xenpvh = kern/i386/xen/pvh.c;
+ i386_xenpvh = term/xen/console.c;
+ i386_xenpvh = disk/xen/xendisk.c;
+
ia64_efi = kern/ia64/efi/startup.S;
ia64_efi = kern/ia64/efi/init.c;
ia64_efi = kern/ia64/dl.c;
@@ -801,6 +813,7 @@ module = {
name = cpuid;
common = commands/i386/cpuid.c;
enable = x86;
+ enable = i386_xenpvh;
enable = i386_xen;
enable = x86_64_xen;
};
@@ -860,6 +873,7 @@ module = {
i386_coreboot = lib/i386/halt.c;
i386_qemu = lib/i386/halt.c;
xen = lib/xen/halt.c;
+ i386_xenpvh = lib/xen/halt.c;
efi = lib/efi/halt.c;
ieee1275 = lib/ieee1275/halt.c;
emu = lib/emu/halt.c;
@@ -877,6 +891,7 @@ module = {
mips_loongson = lib/mips/loongson/reboot.c;
mips_qemu_mips = lib/mips/qemu_mips/reboot.c;
xen = lib/xen/reboot.c;
+ i386_xenpvh = lib/xen/reboot.c;
uboot = lib/uboot/reboot.c;
arm_coreboot = lib/dummy/reboot.c;
common = commands/reboot.c;
@@ -1545,12 +1560,18 @@ module = {
x86 = lib/i386/relocator16.S;
x86 = lib/i386/relocator32.S;
x86 = lib/i386/relocator64.S;
+ i386_xenpvh = lib/i386/relocator16.S;
+ i386_xenpvh = lib/i386/relocator32.S;
+ i386_xenpvh = lib/i386/relocator64.S;
i386 = lib/i386/relocator_asm.S;
+ i386_xenpvh = lib/i386/relocator_asm.S;
x86_64 = lib/x86_64/relocator_asm.S;
i386_xen = lib/i386/relocator_asm.S;
x86_64_xen = lib/x86_64/relocator_asm.S;
x86 = lib/i386/relocator.c;
x86 = lib/i386/relocator_common_c.c;
+ i386_xenpvh = lib/i386/relocator.c;
+ i386_xenpvh = lib/i386/relocator_common_c.c;
ieee1275 = lib/ieee1275/relocator.c;
efi = lib/efi/relocator.c;
mips = lib/mips/relocator_asm.S;
@@ -1569,6 +1590,7 @@ module = {
enable = mips;
enable = powerpc;
enable = x86;
+ enable = i386_xenpvh;
enable = xen;
};
@@ -1583,6 +1605,7 @@ module = {
sparc64_ieee1275 = lib/ieee1275/cmos.c;
powerpc_ieee1275 = lib/ieee1275/cmos.c;
xen = lib/xen/datetime.c;
+ i386_xenpvh = lib/xen/datetime.c;
mips_arc = lib/arc/datetime.c;
enable = noemu;
@@ -1666,6 +1689,7 @@ module = {
common = loader/multiboot.c;
common = loader/multiboot_mbi2.c;
enable = x86;
+ enable = i386_xenpvh;
enable = mips;
};
@@ -1673,8 +1697,10 @@ module = {
name = multiboot;
common = loader/multiboot.c;
x86 = loader/i386/multiboot_mbi.c;
+ i386_xenpvh = loader/i386/multiboot_mbi.c;
extra_dist = loader/multiboot_elfxx.c;
enable = x86;
+ enable = i386_xenpvh;
};
module = {
@@ -1686,8 +1712,10 @@ module = {
module = {
name = linux;
x86 = loader/i386/linux.c;
+ i386_xenpvh = loader/i386/linux.c;
xen = loader/i386/xen.c;
i386_pc = lib/i386/pc/vesa_modes_table.c;
+ i386_xenpvh = lib/i386/pc/vesa_modes_table.c;
mips = loader/mips/linux.c;
powerpc_ieee1275 = loader/powerpc/ieee1275/linux.c;
sparc64_ieee1275 = loader/sparc64/ieee1275/linux.c;
@@ -1775,6 +1803,8 @@ module = {
common = mmap/mmap.c;
x86 = mmap/i386/uppermem.c;
x86 = mmap/i386/mmap.c;
+ i386_xenpvh = mmap/i386/uppermem.c;
+ i386_xenpvh = mmap/i386/mmap.c;
i386_pc = mmap/i386/pc/mmap.c;
i386_pc = mmap/i386/pc/mmap_helper.S;
@@ -1784,6 +1814,7 @@ module = {
mips = mmap/mips/uppermem.c;
enable = x86;
+ enable = i386_xenpvh;
enable = ia64_efi;
enable = arm_efi;
enable = arm64_efi;
@@ -2023,6 +2054,7 @@ module = {
name = legacy_password_test;
common = tests/legacy_password_test.c;
enable = i386_pc;
+ enable = i386_xenpvh;
enable = i386_efi;
enable = x86_64_efi;
enable = emu;
@@ -2221,6 +2253,7 @@ module = {
xen = lib/i386/pc/vesa_modes_table.c;
enable = i386_pc;
+ enable = i386_xenpvh;
enable = i386_efi;
enable = x86_64_efi;
enable = emu;
@@ -2264,10 +2297,12 @@ module = {
module = {
name = backtrace;
x86 = lib/i386/backtrace.c;
+ i386_xenpvh = lib/i386/backtrace.c;
i386_xen = lib/i386/backtrace.c;
x86_64_xen = lib/i386/backtrace.c;
common = lib/backtrace.c;
enable = x86;
+ enable = i386_xenpvh;
enable = i386_xen;
enable = x86_64_xen;
};
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 14/18] xenpvh: add build runes for grub-core
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-22 11:41 ` Daniel Kiper
2018-10-22 11:45 ` Juergen Gross
-1 siblings, 1 reply; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:41 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:13PM +0200, Juergen Gross wrote:
> Add the modifications to the build system needed to build a xenpvh
> grub.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
> gentpl.py | 4 ++--
> grub-core/Makefile.am | 12 ++++++++++++
> grub-core/Makefile.core.def | 35 +++++++++++++++++++++++++++++++++++
> 3 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/gentpl.py b/gentpl.py
> index da67965a4..9732b4aee 100644
> --- a/gentpl.py
> +++ b/gentpl.py
> @@ -28,7 +28,7 @@ import re
>
> GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
> "i386_multiboot", "i386_ieee1275", "x86_64_efi",
> - "i386_xen", "x86_64_xen",
> + "i386_xen", "x86_64_xen", "i386_xenpvh",
s/i386_xenpvh/i386_xen_pvh/ here and below please...
> "mips_loongson", "sparc64_ieee1275",
> "powerpc_ieee1275", "mips_arc", "ia64_efi",
> "mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
> @@ -71,7 +71,7 @@ GROUPS["videomodules"] = GRUB_PLATFORMS[:];
> for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
>
> # Similar for terminfo
> -GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
> +GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
> GROUPS["terminfomodule"] = GRUB_PLATFORMS[:];
> for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
>
> diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
> index f4ff62b76..d4417e2c4 100644
> --- a/grub-core/Makefile.am
> +++ b/grub-core/Makefile.am
> @@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
> endif
>
> +if COND_i386_xenpvh
> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
> +endif
> +
> if COND_i386_efi
> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 9590e87d9..c42cebc38 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -79,6 +79,8 @@ kernel = {
> i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
> x86_64_xen_ldflags = '$(TARGET_IMG_LDFLAGS)';
> x86_64_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
> + i386_xenpvh_ldflags = '$(TARGET_IMG_LDFLAGS)';
> + i386_xenpvh_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x100000';
>
> mips_loongson_ldflags = '-Wl,-Ttext,0x80200000';
> powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000';
> @@ -100,6 +102,7 @@ kernel = {
> x86_64_efi_startup = kern/x86_64/efi/startup.S;
> i386_xen_startup = kern/i386/xen/startup.S;
> x86_64_xen_startup = kern/x86_64/xen/startup.S;
> + i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
> i386_qemu_startup = kern/i386/qemu/startup.S;
> i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
> i386_coreboot_startup = kern/i386/coreboot/startup.S;
> @@ -177,6 +180,7 @@ kernel = {
>
> i386 = kern/i386/dl.c;
> i386_xen = kern/i386/dl.c;
> + i386_xenpvh = kern/i386/dl.c;
>
> i386_coreboot = kern/i386/coreboot/init.c;
> i386_multiboot = kern/i386/coreboot/init.c;
> @@ -222,6 +226,14 @@ kernel = {
> xen = disk/xen/xendisk.c;
> xen = commands/boot.c;
>
> + i386_xenpvh = kern/i386/tsc.c;
> + i386_xenpvh = kern/i386/xen/tsc.c;
> + i386_xenpvh = commands/boot.c;
> + i386_xenpvh = kern/xen/init.c;
> + i386_xenpvh = kern/i386/xen/pvh.c;
> + i386_xenpvh = term/xen/console.c;
> + i386_xenpvh = disk/xen/xendisk.c;
I would sort all file names here.
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 14/18] xenpvh: add build runes for grub-core
2018-10-22 11:41 ` Daniel Kiper
@ 2018-10-22 11:45 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-22 11:45 UTC (permalink / raw)
To: Daniel Kiper; +Cc: hans, grub-devel, phcoder, xen-devel
On 22/10/2018 13:41, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:13PM +0200, Juergen Gross wrote:
>> Add the modifications to the build system needed to build a xenpvh
>> grub.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
>> ---
>> gentpl.py | 4 ++--
>> grub-core/Makefile.am | 12 ++++++++++++
>> grub-core/Makefile.core.def | 35 +++++++++++++++++++++++++++++++++++
>> 3 files changed, 49 insertions(+), 2 deletions(-)
>>
>> diff --git a/gentpl.py b/gentpl.py
>> index da67965a4..9732b4aee 100644
>> --- a/gentpl.py
>> +++ b/gentpl.py
>> @@ -28,7 +28,7 @@ import re
>>
>> GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
>> "i386_multiboot", "i386_ieee1275", "x86_64_efi",
>> - "i386_xen", "x86_64_xen",
>> + "i386_xen", "x86_64_xen", "i386_xenpvh",
>
> s/i386_xenpvh/i386_xen_pvh/ here and below please...
... which is the answer to the question I had to your request for patch
07. I'll change it accordingly.
>
>> "mips_loongson", "sparc64_ieee1275",
>> "powerpc_ieee1275", "mips_arc", "ia64_efi",
>> "mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
>> @@ -71,7 +71,7 @@ GROUPS["videomodules"] = GRUB_PLATFORMS[:];
>> for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
>>
>> # Similar for terminfo
>> -GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
>> +GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
>> GROUPS["terminfomodule"] = GRUB_PLATFORMS[:];
>> for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
>>
>> diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
>> index f4ff62b76..d4417e2c4 100644
>> --- a/grub-core/Makefile.am
>> +++ b/grub-core/Makefile.am
>> @@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
>> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
>> endif
>>
>> +if COND_i386_xenpvh
>> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
>> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
>> +endif
>> +
>> if COND_i386_efi
>> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
>> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
>> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
>> index 9590e87d9..c42cebc38 100644
>> --- a/grub-core/Makefile.core.def
>> +++ b/grub-core/Makefile.core.def
>> @@ -79,6 +79,8 @@ kernel = {
>> i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
>> x86_64_xen_ldflags = '$(TARGET_IMG_LDFLAGS)';
>> x86_64_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
>> + i386_xenpvh_ldflags = '$(TARGET_IMG_LDFLAGS)';
>> + i386_xenpvh_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x100000';
>>
>> mips_loongson_ldflags = '-Wl,-Ttext,0x80200000';
>> powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000';
>> @@ -100,6 +102,7 @@ kernel = {
>> x86_64_efi_startup = kern/x86_64/efi/startup.S;
>> i386_xen_startup = kern/i386/xen/startup.S;
>> x86_64_xen_startup = kern/x86_64/xen/startup.S;
>> + i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
>> i386_qemu_startup = kern/i386/qemu/startup.S;
>> i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
>> i386_coreboot_startup = kern/i386/coreboot/startup.S;
>> @@ -177,6 +180,7 @@ kernel = {
>>
>> i386 = kern/i386/dl.c;
>> i386_xen = kern/i386/dl.c;
>> + i386_xenpvh = kern/i386/dl.c;
>>
>> i386_coreboot = kern/i386/coreboot/init.c;
>> i386_multiboot = kern/i386/coreboot/init.c;
>> @@ -222,6 +226,14 @@ kernel = {
>> xen = disk/xen/xendisk.c;
>> xen = commands/boot.c;
>>
>> + i386_xenpvh = kern/i386/tsc.c;
>> + i386_xenpvh = kern/i386/xen/tsc.c;
>> + i386_xenpvh = commands/boot.c;
>> + i386_xenpvh = kern/xen/init.c;
>> + i386_xenpvh = kern/i386/xen/pvh.c;
>> + i386_xenpvh = term/xen/console.c;
>> + i386_xenpvh = disk/xen/xendisk.c;
>
> I would sort all file names here.
Okay.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 14/18] xenpvh: add build runes for grub-core
@ 2018-10-22 11:45 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-22 11:45 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, xen-devel, phcoder, hans
On 22/10/2018 13:41, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:13PM +0200, Juergen Gross wrote:
>> Add the modifications to the build system needed to build a xenpvh
>> grub.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
>> ---
>> gentpl.py | 4 ++--
>> grub-core/Makefile.am | 12 ++++++++++++
>> grub-core/Makefile.core.def | 35 +++++++++++++++++++++++++++++++++++
>> 3 files changed, 49 insertions(+), 2 deletions(-)
>>
>> diff --git a/gentpl.py b/gentpl.py
>> index da67965a4..9732b4aee 100644
>> --- a/gentpl.py
>> +++ b/gentpl.py
>> @@ -28,7 +28,7 @@ import re
>>
>> GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
>> "i386_multiboot", "i386_ieee1275", "x86_64_efi",
>> - "i386_xen", "x86_64_xen",
>> + "i386_xen", "x86_64_xen", "i386_xenpvh",
>
> s/i386_xenpvh/i386_xen_pvh/ here and below please...
... which is the answer to the question I had to your request for patch
07. I'll change it accordingly.
>
>> "mips_loongson", "sparc64_ieee1275",
>> "powerpc_ieee1275", "mips_arc", "ia64_efi",
>> "mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
>> @@ -71,7 +71,7 @@ GROUPS["videomodules"] = GRUB_PLATFORMS[:];
>> for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
>>
>> # Similar for terminfo
>> -GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
>> +GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
>> GROUPS["terminfomodule"] = GRUB_PLATFORMS[:];
>> for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
>>
>> diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
>> index f4ff62b76..d4417e2c4 100644
>> --- a/grub-core/Makefile.am
>> +++ b/grub-core/Makefile.am
>> @@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
>> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
>> endif
>>
>> +if COND_i386_xenpvh
>> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
>> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
>> +endif
>> +
>> if COND_i386_efi
>> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
>> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
>> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
>> index 9590e87d9..c42cebc38 100644
>> --- a/grub-core/Makefile.core.def
>> +++ b/grub-core/Makefile.core.def
>> @@ -79,6 +79,8 @@ kernel = {
>> i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
>> x86_64_xen_ldflags = '$(TARGET_IMG_LDFLAGS)';
>> x86_64_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
>> + i386_xenpvh_ldflags = '$(TARGET_IMG_LDFLAGS)';
>> + i386_xenpvh_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x100000';
>>
>> mips_loongson_ldflags = '-Wl,-Ttext,0x80200000';
>> powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000';
>> @@ -100,6 +102,7 @@ kernel = {
>> x86_64_efi_startup = kern/x86_64/efi/startup.S;
>> i386_xen_startup = kern/i386/xen/startup.S;
>> x86_64_xen_startup = kern/x86_64/xen/startup.S;
>> + i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
>> i386_qemu_startup = kern/i386/qemu/startup.S;
>> i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
>> i386_coreboot_startup = kern/i386/coreboot/startup.S;
>> @@ -177,6 +180,7 @@ kernel = {
>>
>> i386 = kern/i386/dl.c;
>> i386_xen = kern/i386/dl.c;
>> + i386_xenpvh = kern/i386/dl.c;
>>
>> i386_coreboot = kern/i386/coreboot/init.c;
>> i386_multiboot = kern/i386/coreboot/init.c;
>> @@ -222,6 +226,14 @@ kernel = {
>> xen = disk/xen/xendisk.c;
>> xen = commands/boot.c;
>>
>> + i386_xenpvh = kern/i386/tsc.c;
>> + i386_xenpvh = kern/i386/xen/tsc.c;
>> + i386_xenpvh = commands/boot.c;
>> + i386_xenpvh = kern/xen/init.c;
>> + i386_xenpvh = kern/i386/xen/pvh.c;
>> + i386_xenpvh = term/xen/console.c;
>> + i386_xenpvh = disk/xen/xendisk.c;
>
> I would sort all file names here.
Okay.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 14/18] xenpvh: add build runes for grub-core
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-22 11:41 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:41 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:13PM +0200, Juergen Gross wrote:
> Add the modifications to the build system needed to build a xenpvh
> grub.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
> gentpl.py | 4 ++--
> grub-core/Makefile.am | 12 ++++++++++++
> grub-core/Makefile.core.def | 35 +++++++++++++++++++++++++++++++++++
> 3 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/gentpl.py b/gentpl.py
> index da67965a4..9732b4aee 100644
> --- a/gentpl.py
> +++ b/gentpl.py
> @@ -28,7 +28,7 @@ import re
>
> GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
> "i386_multiboot", "i386_ieee1275", "x86_64_efi",
> - "i386_xen", "x86_64_xen",
> + "i386_xen", "x86_64_xen", "i386_xenpvh",
s/i386_xenpvh/i386_xen_pvh/ here and below please...
> "mips_loongson", "sparc64_ieee1275",
> "powerpc_ieee1275", "mips_arc", "ia64_efi",
> "mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
> @@ -71,7 +71,7 @@ GROUPS["videomodules"] = GRUB_PLATFORMS[:];
> for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
>
> # Similar for terminfo
> -GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
> +GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
> GROUPS["terminfomodule"] = GRUB_PLATFORMS[:];
> for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
>
> diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
> index f4ff62b76..d4417e2c4 100644
> --- a/grub-core/Makefile.am
> +++ b/grub-core/Makefile.am
> @@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
> endif
>
> +if COND_i386_xenpvh
> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
> +endif
> +
> if COND_i386_efi
> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
> KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 9590e87d9..c42cebc38 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -79,6 +79,8 @@ kernel = {
> i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
> x86_64_xen_ldflags = '$(TARGET_IMG_LDFLAGS)';
> x86_64_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
> + i386_xenpvh_ldflags = '$(TARGET_IMG_LDFLAGS)';
> + i386_xenpvh_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x100000';
>
> mips_loongson_ldflags = '-Wl,-Ttext,0x80200000';
> powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x200000';
> @@ -100,6 +102,7 @@ kernel = {
> x86_64_efi_startup = kern/x86_64/efi/startup.S;
> i386_xen_startup = kern/i386/xen/startup.S;
> x86_64_xen_startup = kern/x86_64/xen/startup.S;
> + i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
> i386_qemu_startup = kern/i386/qemu/startup.S;
> i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
> i386_coreboot_startup = kern/i386/coreboot/startup.S;
> @@ -177,6 +180,7 @@ kernel = {
>
> i386 = kern/i386/dl.c;
> i386_xen = kern/i386/dl.c;
> + i386_xenpvh = kern/i386/dl.c;
>
> i386_coreboot = kern/i386/coreboot/init.c;
> i386_multiboot = kern/i386/coreboot/init.c;
> @@ -222,6 +226,14 @@ kernel = {
> xen = disk/xen/xendisk.c;
> xen = commands/boot.c;
>
> + i386_xenpvh = kern/i386/tsc.c;
> + i386_xenpvh = kern/i386/xen/tsc.c;
> + i386_xenpvh = commands/boot.c;
> + i386_xenpvh = kern/xen/init.c;
> + i386_xenpvh = kern/i386/xen/pvh.c;
> + i386_xenpvh = term/xen/console.c;
> + i386_xenpvh = disk/xen/xendisk.c;
I would sort all file names here.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 15/18] grub-module-verifier: Ignore all_video for xenpvh
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
From: Hans van Kranenburg <hans@knorrie.org>
This solves the build failing with "Error: no symbol table and no
.moddeps section"
Also see:
- 6371e9c10433578bb236a8284ddb9ce9e201eb59
- https://savannah.gnu.org/bugs/?49012
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
---
V2: new patch
Signed-off-by: Juergen Gross <jgross@suse.com>
---
util/grub-module-verifier.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/util/grub-module-verifier.c b/util/grub-module-verifier.c
index 03ba1ab43..30baa43df 100644
--- a/util/grub-module-verifier.c
+++ b/util/grub-module-verifier.c
@@ -129,6 +129,7 @@ struct platform_whitelist {
static struct platform_whitelist whitelists[] = {
{"i386", "xen", (const char *[]) {"all_video", 0}},
+ {"i386", "xenpvh", (const char *[]) {"all_video", 0}},
{"x86_64", "xen", (const char *[]) {"all_video", 0}},
{"sparc64", "ieee1275", (const char *[]) {"all_video", 0}},
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 15/18] grub-module-verifier: Ignore all_video for xenpvh
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
From: Hans van Kranenburg <hans@knorrie.org>
This solves the build failing with "Error: no symbol table and no
.moddeps section"
Also see:
- 6371e9c10433578bb236a8284ddb9ce9e201eb59
- https://savannah.gnu.org/bugs/?49012
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
---
V2: new patch
Signed-off-by: Juergen Gross <jgross@suse.com>
---
util/grub-module-verifier.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/util/grub-module-verifier.c b/util/grub-module-verifier.c
index 03ba1ab43..30baa43df 100644
--- a/util/grub-module-verifier.c
+++ b/util/grub-module-verifier.c
@@ -129,6 +129,7 @@ struct platform_whitelist {
static struct platform_whitelist whitelists[] = {
{"i386", "xen", (const char *[]) {"all_video", 0}},
+ {"i386", "xenpvh", (const char *[]) {"all_video", 0}},
{"x86_64", "xen", (const char *[]) {"all_video", 0}},
{"sparc64", "ieee1275", (const char *[]) {"all_video", 0}},
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 15/18] grub-module-verifier: Ignore all_video for xenpvh
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-22 11:45 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:45 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:14PM +0200, Juergen Gross wrote:
> From: Hans van Kranenburg <hans@knorrie.org>
>
> This solves the build failing with "Error: no symbol table and no
> .moddeps section"
>
> Also see:
> - 6371e9c10433578bb236a8284ddb9ce9e201eb59
> - https://savannah.gnu.org/bugs/?49012
>
> Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Except s/xenpvh/xen_pvh/ Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 15/18] grub-module-verifier: Ignore all_video for xenpvh
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-22 11:45 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:45 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:14PM +0200, Juergen Gross wrote:
> From: Hans van Kranenburg <hans@knorrie.org>
>
> This solves the build failing with "Error: no symbol table and no
> .moddeps section"
>
> Also see:
> - 6371e9c10433578bb236a8284ddb9ce9e201eb59
> - https://savannah.gnu.org/bugs/?49012
>
> Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Except s/xenpvh/xen_pvh/ Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 16/18] xenpvh: support building a standalone image
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Support mkimage for xenpvh.
In order to avoid using plain integers for the ELF notes use the
available Xen include instead. While at it replace the plain numbers
for Xen PV mode, too.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: some style adjustments (Daniel Kiper)
use defines for elf-notes (Daniel Kiper)
I didn't replace the 4096 by a PAGE_SIZE macro as requested by Daniel,
as there isn't such a macro easily available for util/mkimage.c and
I didn't introduce its usage.
---
include/grub/util/mkimage.h | 3 ++-
util/grub-mkimage32.c | 4 +++-
util/grub-mkimage64.c | 4 +++-
util/grub-mkimagexx.c | 58 +++++++++++++++++++++++++++++++++++++--------
util/mkimage.c | 23 +++++++++++++++++-
5 files changed, 78 insertions(+), 14 deletions(-)
diff --git a/include/grub/util/mkimage.h b/include/grub/util/mkimage.h
index b3a5ca132..3f5bc2e00 100644
--- a/include/grub/util/mkimage.h
+++ b/include/grub/util/mkimage.h
@@ -71,7 +71,8 @@ struct grub_install_image_target_desc
IMAGE_I386_IEEE1275,
IMAGE_LOONGSON_ELF, IMAGE_QEMU, IMAGE_PPC, IMAGE_YEELOONG_FLASH,
IMAGE_FULOONG2F_FLASH, IMAGE_I386_PC_PXE, IMAGE_MIPS_ARC,
- IMAGE_QEMU_MIPS_FLASH, IMAGE_UBOOT, IMAGE_XEN, IMAGE_I386_PC_ELTORITO
+ IMAGE_QEMU_MIPS_FLASH, IMAGE_UBOOT, IMAGE_XEN, IMAGE_I386_PC_ELTORITO,
+ IMAGE_XENPVH
} id;
enum
{
diff --git a/util/grub-mkimage32.c b/util/grub-mkimage32.c
index 1f2ccccd2..409d487d6 100644
--- a/util/grub-mkimage32.c
+++ b/util/grub-mkimage32.c
@@ -17,7 +17,9 @@
# define ELF_R_SYM(val) ELF32_R_SYM(val)
# define ELF_R_TYPE(val) ELF32_R_TYPE(val)
# define ELF_ST_TYPE(val) ELF32_ST_TYPE(val)
-#define XEN_NOTE_SIZE 132
+
+#define XEN_NOTE_SIZE 132
+#define XENPVH_NOTE_SIZE 20
#ifndef GRUB_MKIMAGEXX
#include "grub-mkimagexx.c"
diff --git a/util/grub-mkimage64.c b/util/grub-mkimage64.c
index 4ff72a625..8bc93ea5a 100644
--- a/util/grub-mkimage64.c
+++ b/util/grub-mkimage64.c
@@ -17,7 +17,9 @@
# define ELF_R_SYM(val) ELF64_R_SYM(val)
# define ELF_R_TYPE(val) ELF64_R_TYPE(val)
# define ELF_ST_TYPE(val) ELF64_ST_TYPE(val)
-#define XEN_NOTE_SIZE 120
+
+#define XEN_NOTE_SIZE 120
+#define XENPVH_NOTE_SIZE 24
#ifndef GRUB_MKIMAGEXX
#include "grub-mkimagexx.c"
diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
index a483c674c..3009a3755 100644
--- a/util/grub-mkimagexx.c
+++ b/util/grub-mkimagexx.c
@@ -48,6 +48,8 @@
#include <grub/util/install.h>
#include <grub/util/mkimage.h>
+#include <xen/elfnote.h>
+
#pragma GCC diagnostic ignored "-Wcast-align"
#define GRUB_MKIMAGEXX
@@ -227,12 +229,12 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
phnum++;
footer_size += sizeof (struct grub_ieee1275_note);
}
- if (image_target->id == IMAGE_XEN)
+ if (image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH)
{
phnum++;
shnum++;
string_size += sizeof (".xen");
- footer_size += XEN_NOTE_SIZE;
+ footer_size += (image_target->id == IMAGE_XEN) ? XEN_NOTE_SIZE : XENPVH_NOTE_SIZE;
}
header_size = ALIGN_UP (sizeof (*ehdr) + phnum * sizeof (*phdr)
+ shnum * sizeof (*shdr) + string_size, layout->align);
@@ -341,7 +343,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof (PACKAGE_NAME));
- note_ptr->n_type = grub_host_to_target32 (6);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_GUEST_OS);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -352,7 +354,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof ("generic"));
- note_ptr->n_type = grub_host_to_target32 (8);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_LOADER);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -363,7 +365,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof ("xen-3.0"));
- note_ptr->n_type = grub_host_to_target32 (5);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_XEN_VERSION);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -374,7 +376,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (image_target->voidp_sizeof);
- note_ptr->n_type = grub_host_to_target32 (1);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_ENTRY);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -385,7 +387,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (image_target->voidp_sizeof);
- note_ptr->n_type = grub_host_to_target32 (3);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_VIRT_BASE);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -398,7 +400,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof ("yes,bimodal"));
- note_ptr->n_type = grub_host_to_target32 (9);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_PAE_MODE);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -419,6 +421,39 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
phdr->p_offset = grub_host_to_target32 (header_size + program_size);
}
+ if (image_target->id == IMAGE_XENPVH)
+ {
+ char *note_start = (elf_img + program_size + header_size);
+ Elf_Nhdr *note_ptr;
+ char *ptr = (char *) note_start;
+
+ grub_util_info ("adding XEN NOTE segment");
+
+ /* Phys32 Entry. */
+ note_ptr = (Elf_Nhdr *) ptr;
+ note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
+ note_ptr->n_descsz = grub_host_to_target32 (image_target->voidp_sizeof);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_PHYS32_ENTRY);
+ ptr += sizeof (Elf_Nhdr);
+ memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
+ ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
+ memset (ptr, 0, image_target->voidp_sizeof);
+ *(grub_uint32_t *) ptr = GRUB_KERNEL_I386_XENPVH_LINK_ADDR;
+ ptr += image_target->voidp_sizeof;
+
+ assert (XENPVH_NOTE_SIZE == (ptr - note_start));
+
+ phdr++;
+ phdr->p_type = grub_host_to_target32 (PT_NOTE);
+ phdr->p_flags = grub_host_to_target32 (PF_R);
+ phdr->p_align = grub_host_to_target32 (image_target->voidp_sizeof);
+ phdr->p_vaddr = 0;
+ phdr->p_paddr = 0;
+ phdr->p_filesz = grub_host_to_target32 (XENPVH_NOTE_SIZE);
+ phdr->p_memsz = 0;
+ phdr->p_offset = grub_host_to_target32 (header_size + program_size);
+ }
+
if (note)
{
int note_size = sizeof (struct grub_ieee1275_note);
@@ -494,7 +529,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
shdr->sh_entsize = grub_host_to_target32 (0);
shdr++;
- if (image_target->id == IMAGE_XEN)
+ if (image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH)
{
memcpy (ptr, ".xen", sizeof (".xen"));
shdr->sh_name = grub_host_to_target32 (ptr - str_start);
@@ -502,7 +537,10 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
shdr->sh_type = grub_host_to_target32 (SHT_PROGBITS);
shdr->sh_addr = grub_host_to_target_addr (target_addr + layout->kernel_size);
shdr->sh_offset = grub_host_to_target_addr (program_size + header_size);
- shdr->sh_size = grub_host_to_target32 (XEN_NOTE_SIZE);
+ if (image_target->id == IMAGE_XEN)
+ shdr->sh_size = grub_host_to_target32 (XEN_NOTE_SIZE);
+ else
+ shdr->sh_size = grub_host_to_target32 (XENPVH_NOTE_SIZE);
shdr->sh_link = grub_host_to_target32 (0);
shdr->sh_info = grub_host_to_target32 (0);
shdr->sh_addralign = grub_host_to_target32 (image_target->voidp_sizeof);
diff --git a/util/mkimage.c b/util/mkimage.c
index e22d82afa..5e071c074 100644
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -132,6 +132,24 @@ static const struct grub_install_image_target_desc image_targets[] =
.link_addr = GRUB_KERNEL_I386_PC_LINK_ADDR,
.default_compression = GRUB_COMPRESSION_LZMA
},
+ {
+ .dirname = "i386-xenpvh",
+ .names = { "i386-xenpvh", NULL },
+ .voidp_sizeof = 4,
+ .bigendian = 0,
+ .id = IMAGE_XENPVH,
+ .flags = PLATFORM_FLAGS_NONE,
+ .total_module_size = TARGET_NO_FIELD,
+ .decompressor_compressed_size = TARGET_NO_FIELD,
+ .decompressor_uncompressed_size = TARGET_NO_FIELD,
+ .decompressor_uncompressed_addr = TARGET_NO_FIELD,
+ .elf_target = EM_386,
+ .section_align = 1,
+ .vaddr_offset = 0,
+ .link_addr = GRUB_KERNEL_I386_XENPVH_LINK_ADDR,
+ .mod_align = GRUB_KERNEL_I386_XENPVH_MOD_ALIGN,
+ .link_align = 4
+ },
{
.dirname = "i386-pc",
.names = { "i386-pc-pxe", NULL },
@@ -860,7 +878,8 @@ grub_install_generate_image (const char *dir, const char *prefix,
else
kernel_img = grub_mkimage_load_image64 (kernel_path, total_module_size,
&layout, image_target);
- if (image_target->id == IMAGE_XEN && layout.align < 4096)
+ if ((image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH) &&
+ layout.align < 4096)
layout.align = 4096;
if ((image_target->flags & PLATFORM_FLAGS_DECOMPRESSORS)
@@ -1103,6 +1122,7 @@ grub_install_generate_image (const char *dir, const char *prefix,
case IMAGE_MIPS_ARC:
case IMAGE_QEMU_MIPS_FLASH:
case IMAGE_XEN:
+ case IMAGE_XENPVH:
break;
case IMAGE_SPARC64_AOUT:
case IMAGE_SPARC64_RAW:
@@ -1679,6 +1699,7 @@ grub_install_generate_image (const char *dir, const char *prefix,
case IMAGE_LOONGSON_ELF:
case IMAGE_PPC:
case IMAGE_XEN:
+ case IMAGE_XENPVH:
case IMAGE_COREBOOT:
case IMAGE_I386_IEEE1275:
{
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 16/18] xenpvh: support building a standalone image
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Support mkimage for xenpvh.
In order to avoid using plain integers for the ELF notes use the
available Xen include instead. While at it replace the plain numbers
for Xen PV mode, too.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2: some style adjustments (Daniel Kiper)
use defines for elf-notes (Daniel Kiper)
I didn't replace the 4096 by a PAGE_SIZE macro as requested by Daniel,
as there isn't such a macro easily available for util/mkimage.c and
I didn't introduce its usage.
---
include/grub/util/mkimage.h | 3 ++-
util/grub-mkimage32.c | 4 +++-
util/grub-mkimage64.c | 4 +++-
util/grub-mkimagexx.c | 58 +++++++++++++++++++++++++++++++++++++--------
util/mkimage.c | 23 +++++++++++++++++-
5 files changed, 78 insertions(+), 14 deletions(-)
diff --git a/include/grub/util/mkimage.h b/include/grub/util/mkimage.h
index b3a5ca132..3f5bc2e00 100644
--- a/include/grub/util/mkimage.h
+++ b/include/grub/util/mkimage.h
@@ -71,7 +71,8 @@ struct grub_install_image_target_desc
IMAGE_I386_IEEE1275,
IMAGE_LOONGSON_ELF, IMAGE_QEMU, IMAGE_PPC, IMAGE_YEELOONG_FLASH,
IMAGE_FULOONG2F_FLASH, IMAGE_I386_PC_PXE, IMAGE_MIPS_ARC,
- IMAGE_QEMU_MIPS_FLASH, IMAGE_UBOOT, IMAGE_XEN, IMAGE_I386_PC_ELTORITO
+ IMAGE_QEMU_MIPS_FLASH, IMAGE_UBOOT, IMAGE_XEN, IMAGE_I386_PC_ELTORITO,
+ IMAGE_XENPVH
} id;
enum
{
diff --git a/util/grub-mkimage32.c b/util/grub-mkimage32.c
index 1f2ccccd2..409d487d6 100644
--- a/util/grub-mkimage32.c
+++ b/util/grub-mkimage32.c
@@ -17,7 +17,9 @@
# define ELF_R_SYM(val) ELF32_R_SYM(val)
# define ELF_R_TYPE(val) ELF32_R_TYPE(val)
# define ELF_ST_TYPE(val) ELF32_ST_TYPE(val)
-#define XEN_NOTE_SIZE 132
+
+#define XEN_NOTE_SIZE 132
+#define XENPVH_NOTE_SIZE 20
#ifndef GRUB_MKIMAGEXX
#include "grub-mkimagexx.c"
diff --git a/util/grub-mkimage64.c b/util/grub-mkimage64.c
index 4ff72a625..8bc93ea5a 100644
--- a/util/grub-mkimage64.c
+++ b/util/grub-mkimage64.c
@@ -17,7 +17,9 @@
# define ELF_R_SYM(val) ELF64_R_SYM(val)
# define ELF_R_TYPE(val) ELF64_R_TYPE(val)
# define ELF_ST_TYPE(val) ELF64_ST_TYPE(val)
-#define XEN_NOTE_SIZE 120
+
+#define XEN_NOTE_SIZE 120
+#define XENPVH_NOTE_SIZE 24
#ifndef GRUB_MKIMAGEXX
#include "grub-mkimagexx.c"
diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
index a483c674c..3009a3755 100644
--- a/util/grub-mkimagexx.c
+++ b/util/grub-mkimagexx.c
@@ -48,6 +48,8 @@
#include <grub/util/install.h>
#include <grub/util/mkimage.h>
+#include <xen/elfnote.h>
+
#pragma GCC diagnostic ignored "-Wcast-align"
#define GRUB_MKIMAGEXX
@@ -227,12 +229,12 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
phnum++;
footer_size += sizeof (struct grub_ieee1275_note);
}
- if (image_target->id == IMAGE_XEN)
+ if (image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH)
{
phnum++;
shnum++;
string_size += sizeof (".xen");
- footer_size += XEN_NOTE_SIZE;
+ footer_size += (image_target->id == IMAGE_XEN) ? XEN_NOTE_SIZE : XENPVH_NOTE_SIZE;
}
header_size = ALIGN_UP (sizeof (*ehdr) + phnum * sizeof (*phdr)
+ shnum * sizeof (*shdr) + string_size, layout->align);
@@ -341,7 +343,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof (PACKAGE_NAME));
- note_ptr->n_type = grub_host_to_target32 (6);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_GUEST_OS);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -352,7 +354,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof ("generic"));
- note_ptr->n_type = grub_host_to_target32 (8);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_LOADER);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -363,7 +365,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof ("xen-3.0"));
- note_ptr->n_type = grub_host_to_target32 (5);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_XEN_VERSION);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -374,7 +376,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (image_target->voidp_sizeof);
- note_ptr->n_type = grub_host_to_target32 (1);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_ENTRY);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -385,7 +387,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (image_target->voidp_sizeof);
- note_ptr->n_type = grub_host_to_target32 (3);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_VIRT_BASE);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -398,7 +400,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
note_ptr = (Elf_Nhdr *) ptr;
note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
note_ptr->n_descsz = grub_host_to_target32 (sizeof ("yes,bimodal"));
- note_ptr->n_type = grub_host_to_target32 (9);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_PAE_MODE);
ptr += sizeof (Elf_Nhdr);
memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
@@ -419,6 +421,39 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
phdr->p_offset = grub_host_to_target32 (header_size + program_size);
}
+ if (image_target->id == IMAGE_XENPVH)
+ {
+ char *note_start = (elf_img + program_size + header_size);
+ Elf_Nhdr *note_ptr;
+ char *ptr = (char *) note_start;
+
+ grub_util_info ("adding XEN NOTE segment");
+
+ /* Phys32 Entry. */
+ note_ptr = (Elf_Nhdr *) ptr;
+ note_ptr->n_namesz = grub_host_to_target32 (sizeof (GRUB_XEN_NOTE_NAME));
+ note_ptr->n_descsz = grub_host_to_target32 (image_target->voidp_sizeof);
+ note_ptr->n_type = grub_host_to_target32 (XEN_ELFNOTE_PHYS32_ENTRY);
+ ptr += sizeof (Elf_Nhdr);
+ memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
+ ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
+ memset (ptr, 0, image_target->voidp_sizeof);
+ *(grub_uint32_t *) ptr = GRUB_KERNEL_I386_XENPVH_LINK_ADDR;
+ ptr += image_target->voidp_sizeof;
+
+ assert (XENPVH_NOTE_SIZE == (ptr - note_start));
+
+ phdr++;
+ phdr->p_type = grub_host_to_target32 (PT_NOTE);
+ phdr->p_flags = grub_host_to_target32 (PF_R);
+ phdr->p_align = grub_host_to_target32 (image_target->voidp_sizeof);
+ phdr->p_vaddr = 0;
+ phdr->p_paddr = 0;
+ phdr->p_filesz = grub_host_to_target32 (XENPVH_NOTE_SIZE);
+ phdr->p_memsz = 0;
+ phdr->p_offset = grub_host_to_target32 (header_size + program_size);
+ }
+
if (note)
{
int note_size = sizeof (struct grub_ieee1275_note);
@@ -494,7 +529,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
shdr->sh_entsize = grub_host_to_target32 (0);
shdr++;
- if (image_target->id == IMAGE_XEN)
+ if (image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH)
{
memcpy (ptr, ".xen", sizeof (".xen"));
shdr->sh_name = grub_host_to_target32 (ptr - str_start);
@@ -502,7 +537,10 @@ SUFFIX (grub_mkimage_generate_elf) (const struct grub_install_image_target_desc
shdr->sh_type = grub_host_to_target32 (SHT_PROGBITS);
shdr->sh_addr = grub_host_to_target_addr (target_addr + layout->kernel_size);
shdr->sh_offset = grub_host_to_target_addr (program_size + header_size);
- shdr->sh_size = grub_host_to_target32 (XEN_NOTE_SIZE);
+ if (image_target->id == IMAGE_XEN)
+ shdr->sh_size = grub_host_to_target32 (XEN_NOTE_SIZE);
+ else
+ shdr->sh_size = grub_host_to_target32 (XENPVH_NOTE_SIZE);
shdr->sh_link = grub_host_to_target32 (0);
shdr->sh_info = grub_host_to_target32 (0);
shdr->sh_addralign = grub_host_to_target32 (image_target->voidp_sizeof);
diff --git a/util/mkimage.c b/util/mkimage.c
index e22d82afa..5e071c074 100644
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -132,6 +132,24 @@ static const struct grub_install_image_target_desc image_targets[] =
.link_addr = GRUB_KERNEL_I386_PC_LINK_ADDR,
.default_compression = GRUB_COMPRESSION_LZMA
},
+ {
+ .dirname = "i386-xenpvh",
+ .names = { "i386-xenpvh", NULL },
+ .voidp_sizeof = 4,
+ .bigendian = 0,
+ .id = IMAGE_XENPVH,
+ .flags = PLATFORM_FLAGS_NONE,
+ .total_module_size = TARGET_NO_FIELD,
+ .decompressor_compressed_size = TARGET_NO_FIELD,
+ .decompressor_uncompressed_size = TARGET_NO_FIELD,
+ .decompressor_uncompressed_addr = TARGET_NO_FIELD,
+ .elf_target = EM_386,
+ .section_align = 1,
+ .vaddr_offset = 0,
+ .link_addr = GRUB_KERNEL_I386_XENPVH_LINK_ADDR,
+ .mod_align = GRUB_KERNEL_I386_XENPVH_MOD_ALIGN,
+ .link_align = 4
+ },
{
.dirname = "i386-pc",
.names = { "i386-pc-pxe", NULL },
@@ -860,7 +878,8 @@ grub_install_generate_image (const char *dir, const char *prefix,
else
kernel_img = grub_mkimage_load_image64 (kernel_path, total_module_size,
&layout, image_target);
- if (image_target->id == IMAGE_XEN && layout.align < 4096)
+ if ((image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH) &&
+ layout.align < 4096)
layout.align = 4096;
if ((image_target->flags & PLATFORM_FLAGS_DECOMPRESSORS)
@@ -1103,6 +1122,7 @@ grub_install_generate_image (const char *dir, const char *prefix,
case IMAGE_MIPS_ARC:
case IMAGE_QEMU_MIPS_FLASH:
case IMAGE_XEN:
+ case IMAGE_XENPVH:
break;
case IMAGE_SPARC64_AOUT:
case IMAGE_SPARC64_RAW:
@@ -1679,6 +1699,7 @@ grub_install_generate_image (const char *dir, const char *prefix,
case IMAGE_LOONGSON_ELF:
case IMAGE_PPC:
case IMAGE_XEN:
+ case IMAGE_XENPVH:
case IMAGE_COREBOOT:
case IMAGE_I386_IEEE1275:
{
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 16/18] xenpvh: support building a standalone image
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-22 11:56 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:56 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:15PM +0200, Juergen Gross wrote:
> Support mkimage for xenpvh.
>
> In order to avoid using plain integers for the ELF notes use the
> available Xen include instead. While at it replace the plain numbers
> for Xen PV mode, too.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
+/- XENPVH/xenpvh play Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 16/18] xenpvh: support building a standalone image
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-22 11:56 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 11:56 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:15PM +0200, Juergen Gross wrote:
> Support mkimage for xenpvh.
>
> In order to avoid using plain integers for the ELF notes use the
> available Xen include instead. While at it replace the plain numbers
> for Xen PV mode, too.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
+/- XENPVH/xenpvh play Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 17/18] xenpvh: support grub-install for xenpvh
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Add xenpvh support to grub-install.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
include/grub/util/install.h | 1 +
util/grub-install-common.c | 1 +
util/grub-install.c | 7 +++++++
3 files changed, 9 insertions(+)
diff --git a/include/grub/util/install.h b/include/grub/util/install.h
index 0dba8b67f..cba4e84c8 100644
--- a/include/grub/util/install.h
+++ b/include/grub/util/install.h
@@ -100,6 +100,7 @@ enum grub_install_plat
GRUB_INSTALL_PLATFORM_MIPS_QEMU_MIPS,
GRUB_INSTALL_PLATFORM_I386_XEN,
GRUB_INSTALL_PLATFORM_X86_64_XEN,
+ GRUB_INSTALL_PLATFORM_I386_XENPVH,
GRUB_INSTALL_PLATFORM_ARM64_EFI,
GRUB_INSTALL_PLATFORM_ARM_COREBOOT,
GRUB_INSTALL_PLATFORM_MAX
diff --git a/util/grub-install-common.c b/util/grub-install-common.c
index 0a2e24a79..106fde1f3 100644
--- a/util/grub-install-common.c
+++ b/util/grub-install-common.c
@@ -716,6 +716,7 @@ static struct
[GRUB_INSTALL_PLATFORM_X86_64_EFI] = { "x86_64", "efi" },
[GRUB_INSTALL_PLATFORM_I386_XEN] = { "i386", "xen" },
[GRUB_INSTALL_PLATFORM_X86_64_XEN] = { "x86_64", "xen" },
+ [GRUB_INSTALL_PLATFORM_I386_XENPVH] = { "i386", "xenpvh" },
[GRUB_INSTALL_PLATFORM_MIPSEL_LOONGSON] = { "mipsel", "loongson" },
[GRUB_INSTALL_PLATFORM_MIPSEL_QEMU_MIPS] = { "mipsel", "qemu_mips" },
[GRUB_INSTALL_PLATFORM_MIPS_QEMU_MIPS] = { "mips", "qemu_mips" },
diff --git a/util/grub-install.c b/util/grub-install.c
index 4375c1619..a7d751f45 100644
--- a/util/grub-install.c
+++ b/util/grub-install.c
@@ -496,6 +496,7 @@ have_bootdev (enum grub_install_plat pl)
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
return 0;
/* pacify warning. */
@@ -913,6 +914,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_ARM_UBOOT:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
break;
case GRUB_INSTALL_PLATFORM_I386_QEMU:
@@ -960,6 +962,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_MIPS_QEMU_MIPS:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
free (install_device);
install_device = NULL;
break;
@@ -1477,6 +1480,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_ARM_UBOOT:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
grub_util_warn ("%s", _("no hints available for your platform. Expect reduced performance"));
break;
/* pacify warning. */
@@ -1568,6 +1572,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_POWERPC_IEEE1275:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
core_name = "core.elf";
snprintf (mkimage_target, sizeof (mkimage_target),
"%s-%s",
@@ -1660,6 +1665,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_SPARC64_IEEE1275:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
break;
/* pacify warning. */
case GRUB_INSTALL_PLATFORM_MAX:
@@ -1926,6 +1932,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_I386_QEMU:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
grub_util_warn ("%s",
_("WARNING: no platform-specific install was performed"));
break;
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 17/18] xenpvh: support grub-install for xenpvh
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Add xenpvh support to grub-install.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
include/grub/util/install.h | 1 +
util/grub-install-common.c | 1 +
util/grub-install.c | 7 +++++++
3 files changed, 9 insertions(+)
diff --git a/include/grub/util/install.h b/include/grub/util/install.h
index 0dba8b67f..cba4e84c8 100644
--- a/include/grub/util/install.h
+++ b/include/grub/util/install.h
@@ -100,6 +100,7 @@ enum grub_install_plat
GRUB_INSTALL_PLATFORM_MIPS_QEMU_MIPS,
GRUB_INSTALL_PLATFORM_I386_XEN,
GRUB_INSTALL_PLATFORM_X86_64_XEN,
+ GRUB_INSTALL_PLATFORM_I386_XENPVH,
GRUB_INSTALL_PLATFORM_ARM64_EFI,
GRUB_INSTALL_PLATFORM_ARM_COREBOOT,
GRUB_INSTALL_PLATFORM_MAX
diff --git a/util/grub-install-common.c b/util/grub-install-common.c
index 0a2e24a79..106fde1f3 100644
--- a/util/grub-install-common.c
+++ b/util/grub-install-common.c
@@ -716,6 +716,7 @@ static struct
[GRUB_INSTALL_PLATFORM_X86_64_EFI] = { "x86_64", "efi" },
[GRUB_INSTALL_PLATFORM_I386_XEN] = { "i386", "xen" },
[GRUB_INSTALL_PLATFORM_X86_64_XEN] = { "x86_64", "xen" },
+ [GRUB_INSTALL_PLATFORM_I386_XENPVH] = { "i386", "xenpvh" },
[GRUB_INSTALL_PLATFORM_MIPSEL_LOONGSON] = { "mipsel", "loongson" },
[GRUB_INSTALL_PLATFORM_MIPSEL_QEMU_MIPS] = { "mipsel", "qemu_mips" },
[GRUB_INSTALL_PLATFORM_MIPS_QEMU_MIPS] = { "mips", "qemu_mips" },
diff --git a/util/grub-install.c b/util/grub-install.c
index 4375c1619..a7d751f45 100644
--- a/util/grub-install.c
+++ b/util/grub-install.c
@@ -496,6 +496,7 @@ have_bootdev (enum grub_install_plat pl)
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
return 0;
/* pacify warning. */
@@ -913,6 +914,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_ARM_UBOOT:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
break;
case GRUB_INSTALL_PLATFORM_I386_QEMU:
@@ -960,6 +962,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_MIPS_QEMU_MIPS:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
free (install_device);
install_device = NULL;
break;
@@ -1477,6 +1480,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_ARM_UBOOT:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
grub_util_warn ("%s", _("no hints available for your platform. Expect reduced performance"));
break;
/* pacify warning. */
@@ -1568,6 +1572,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_POWERPC_IEEE1275:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
core_name = "core.elf";
snprintf (mkimage_target, sizeof (mkimage_target),
"%s-%s",
@@ -1660,6 +1665,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_SPARC64_IEEE1275:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
break;
/* pacify warning. */
case GRUB_INSTALL_PLATFORM_MAX:
@@ -1926,6 +1932,7 @@ main (int argc, char *argv[])
case GRUB_INSTALL_PLATFORM_I386_QEMU:
case GRUB_INSTALL_PLATFORM_I386_XEN:
case GRUB_INSTALL_PLATFORM_X86_64_XEN:
+ case GRUB_INSTALL_PLATFORM_I386_XENPVH:
grub_util_warn ("%s",
_("WARNING: no platform-specific install was performed"));
break;
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 17/18] xenpvh: support grub-install for xenpvh
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-22 12:01 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 12:01 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:16PM +0200, Juergen Gross wrote:
> Add xenpvh support to grub-install.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+/- XENPVH play still Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 17/18] xenpvh: support grub-install for xenpvh
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-22 12:01 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 12:01 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:16PM +0200, Juergen Gross wrote:
> Add xenpvh support to grub-install.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+/- XENPVH play still Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v2 18/18] xenpvh: add support to configure
2018-10-09 11:02 ` Juergen Gross
@ 2018-10-09 11:03 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, Juergen Gross, xen-devel
Support platform i386/xenpvh in configure.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index 5e63c4af3..96d81a3f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -151,6 +151,7 @@ case "$target_cpu"-"$platform" in
i386-efi) ;;
x86_64-efi) ;;
i386-xen) ;;
+ i386-xenpvh) ;;
x86_64-xen) ;;
i386-pc) ;;
i386-multiboot) ;;
@@ -219,6 +220,7 @@ case "$platform" in
multiboot) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_MULTIBOOT=1" ;;
efi) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_EFI=1" ;;
xen) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_XEN=1" ;;
+ xenpvh) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_XENPVH=1" ;;
ieee1275) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_IEEE1275=1" ;;
uboot) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_UBOOT=1" ;;
qemu) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_QEMU=1" ;;
@@ -1897,6 +1899,7 @@ AM_CONDITIONAL([COND_i386_coreboot], [test x$target_cpu = xi386 -a x$platform =
AM_CONDITIONAL([COND_i386_multiboot], [test x$target_cpu = xi386 -a x$platform = xmultiboot])
AM_CONDITIONAL([COND_x86_64_efi], [test x$target_cpu = xx86_64 -a x$platform = xefi])
AM_CONDITIONAL([COND_i386_xen], [test x$target_cpu = xi386 -a x$platform = xxen])
+AM_CONDITIONAL([COND_i386_xenpvh], [test x$target_cpu = xi386 -a x$platform = xxenpvh])
AM_CONDITIONAL([COND_x86_64_xen], [test x$target_cpu = xx86_64 -a x$platform = xxen])
AM_CONDITIONAL([COND_mips_loongson], [test x$target_cpu = xmipsel -a x$platform = xloongson])
AM_CONDITIONAL([COND_mips_qemu_mips], [test "(" x$target_cpu = xmips -o x$target_cpu = xmipsel ")" -a x$platform = xqemu_mips])
--
2.16.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v2 18/18] xenpvh: add support to configure
@ 2018-10-09 11:03 ` Juergen Gross
0 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-09 11:03 UTC (permalink / raw)
To: grub-devel; +Cc: xen-devel, phcoder, daniel.kiper, hans, Juergen Gross
Support platform i386/xenpvh in configure.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index 5e63c4af3..96d81a3f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -151,6 +151,7 @@ case "$target_cpu"-"$platform" in
i386-efi) ;;
x86_64-efi) ;;
i386-xen) ;;
+ i386-xenpvh) ;;
x86_64-xen) ;;
i386-pc) ;;
i386-multiboot) ;;
@@ -219,6 +220,7 @@ case "$platform" in
multiboot) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_MULTIBOOT=1" ;;
efi) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_EFI=1" ;;
xen) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_XEN=1" ;;
+ xenpvh) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_XENPVH=1" ;;
ieee1275) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_IEEE1275=1" ;;
uboot) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_UBOOT=1" ;;
qemu) machine_CPPFLAGS="$machine_CPPFLAGS -DGRUB_MACHINE_QEMU=1" ;;
@@ -1897,6 +1899,7 @@ AM_CONDITIONAL([COND_i386_coreboot], [test x$target_cpu = xi386 -a x$platform =
AM_CONDITIONAL([COND_i386_multiboot], [test x$target_cpu = xi386 -a x$platform = xmultiboot])
AM_CONDITIONAL([COND_x86_64_efi], [test x$target_cpu = xx86_64 -a x$platform = xefi])
AM_CONDITIONAL([COND_i386_xen], [test x$target_cpu = xi386 -a x$platform = xxen])
+AM_CONDITIONAL([COND_i386_xenpvh], [test x$target_cpu = xi386 -a x$platform = xxenpvh])
AM_CONDITIONAL([COND_x86_64_xen], [test x$target_cpu = xx86_64 -a x$platform = xxen])
AM_CONDITIONAL([COND_mips_loongson], [test x$target_cpu = xmipsel -a x$platform = xloongson])
AM_CONDITIONAL([COND_mips_qemu_mips], [test "(" x$target_cpu = xmips -o x$target_cpu = xmipsel ")" -a x$platform = xqemu_mips])
--
2.16.4
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v2 18/18] xenpvh: add support to configure
2018-10-09 11:03 ` Juergen Gross
(?)
@ 2018-10-22 12:04 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 12:04 UTC (permalink / raw)
To: Juergen Gross; +Cc: grub-devel, xen-devel, phcoder, hans
On Tue, Oct 09, 2018 at 01:03:17PM +0200, Juergen Gross wrote:
> Support platform i386/xenpvh in configure.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+/- XENPVH/xenpvh play still Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v2 18/18] xenpvh: add support to configure
2018-10-09 11:03 ` Juergen Gross
(?)
(?)
@ 2018-10-22 12:04 ` Daniel Kiper
-1 siblings, 0 replies; 148+ messages in thread
From: Daniel Kiper @ 2018-10-22 12:04 UTC (permalink / raw)
To: Juergen Gross; +Cc: hans, grub-devel, phcoder, xen-devel
On Tue, Oct 09, 2018 at 01:03:17PM +0200, Juergen Gross wrote:
> Support platform i386/xenpvh in configure.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+/- XENPVH/xenpvh play still Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [Xen-devel] [PATCH v2 00/18] xen: add pvh guest support
2018-10-09 11:02 ` Juergen Gross
` (20 preceding siblings ...)
(?)
@ 2018-10-10 15:59 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-10 15:59 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, xen-devel
On 09/10/2018 13:02, Juergen Gross wrote:
> This patch series adds support for booting Linux as PVH guest.
>
> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
> platform grub is booted as a standalone image directly by Xen.
>
> For booting Linux kernel it is using the standard linux kernel
> loader. The only modification of the linux loader is to pass the
> ACPI RSDP address via boot parameters to the kernel, as that table
> might not be located at the usual physical address just below 1MB.
>
> As the related Linux kernel patches are not yet accepted please
> wait for this to happen before applying the series. This Linux kernel
> series is available under:
>
> https://lists.xen.org/archives/html/xen-devel/2018-10/msg00776.html
The Linux kernel series is now available under:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/grub2
This means the series has been accepted and is kept pending until
this grub2 series has been accepted.
Juergen
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v2 00/18] xen: add pvh guest support
2018-10-09 11:02 ` Juergen Gross
` (21 preceding siblings ...)
(?)
@ 2018-10-10 15:59 ` Juergen Gross
-1 siblings, 0 replies; 148+ messages in thread
From: Juergen Gross @ 2018-10-10 15:59 UTC (permalink / raw)
To: grub-devel; +Cc: hans, phcoder, daniel.kiper, xen-devel
On 09/10/2018 13:02, Juergen Gross wrote:
> This patch series adds support for booting Linux as PVH guest.
>
> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
> platform grub is booted as a standalone image directly by Xen.
>
> For booting Linux kernel it is using the standard linux kernel
> loader. The only modification of the linux loader is to pass the
> ACPI RSDP address via boot parameters to the kernel, as that table
> might not be located at the usual physical address just below 1MB.
>
> As the related Linux kernel patches are not yet accepted please
> wait for this to happen before applying the series. This Linux kernel
> series is available under:
>
> https://lists.xen.org/archives/html/xen-devel/2018-10/msg00776.html
The Linux kernel series is now available under:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/grub2
This means the series has been accepted and is kept pending until
this grub2 series has been accepted.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 148+ messages in thread