* [PATCH v1 00/12] Introduce xenpv machine for arm architecture
@ 2022-10-15 5:07 Vikram Garhwal
2022-10-15 5:07 ` [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub Vikram Garhwal
` (13 more replies)
0 siblings, 14 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel; +Cc: vikram.garhwal, stefano.stabellini
Hi,
This series add xenpv machine for aarch64. Motivation behind creating xenpv
machine with IOREQ and TPM was to enable each guest on Xen aarch64 to have it's
own unique and emulated TPM.
This series does following:
1. Moved common xen functionalities from hw/i386/xen to hw/xen/ so those can
be used for aarch64.
2. We added a minimal xenpv arm machine which creates an IOREQ server and
support TPM.
Please note that patch 05/12 breaks the build. Patch 06/12 fixes the build
issue. If needed we can merge patch 05/12 and 06/12. For now we kept these
separate to make changes easy to review.
Also, checkpatch.pl fails for 03/12 and 06/12. These fails are due to
moving old code to new place which was not QEMU code style compatible.
No new add code was added.
Regards,
Vikram
Stefano Stabellini (5):
hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState
hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory
include/hw/xen/xen_common: return error from xen_create_ioreq_server
hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration
failure
meson.build: do not set have_xen_pci_passthrough for aarch64 targets
Vikram Garhwal (7):
hw/xen: Correct build config for xen_pt_stub
hw/i386/xen/: move xen-mapcache.c to hw/xen/
hw/i386/xen: rearrange xen_hvm_init_pc
xen-hvm: move common functions to hw/xen/xen-hvm-common.c
accel/xen/xen-all: export xenstore_record_dm_state
hw/arm: introduce xenpv machine
meson.build: enable xenpv machine build for ARM
accel/xen/xen-all.c | 2 +-
hw/arm/meson.build | 2 +
hw/arm/xen_arm.c | 163 +++++
hw/i386/meson.build | 1 +
hw/i386/xen/meson.build | 1 -
hw/i386/xen/trace-events | 19 -
hw/i386/xen/xen-hvm.c | 1084 +++---------------------------
hw/xen/meson.build | 9 +-
hw/xen/trace-events | 19 +
hw/xen/xen-hvm-common.c | 863 ++++++++++++++++++++++++
hw/{i386 => }/xen/xen-mapcache.c | 0
include/hw/arm/xen_arch_hvm.h | 12 +
include/hw/i386/xen_arch_hvm.h | 11 +
include/hw/xen/arch_hvm.h | 5 +
include/hw/xen/xen-hvm-common.h | 97 +++
include/hw/xen/xen.h | 2 +
include/hw/xen/xen_common.h | 12 +-
meson.build | 4 +-
18 files changed, 1287 insertions(+), 1019 deletions(-)
create mode 100644 hw/arm/xen_arm.c
create mode 100644 hw/xen/xen-hvm-common.c
rename hw/{i386 => }/xen/xen-mapcache.c (100%)
create mode 100644 include/hw/arm/xen_arch_hvm.h
create mode 100644 include/hw/i386/xen_arch_hvm.h
create mode 100644 include/hw/xen/arch_hvm.h
create mode 100644 include/hw/xen/xen-hvm-common.h
--
2.17.0
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-19 14:46 ` Paul Durrant
2022-10-26 19:01 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/ Vikram Garhwal
` (12 subsequent siblings)
13 siblings, 2 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, open list:X86 Xen CPUs
Build fails when have_xen_pci_passthrough is disabled. This is because of
incorrect build configuration for xen_pt_stub.c.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
---
hw/xen/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xen/meson.build b/hw/xen/meson.build
index 08dc1f6857..ae0ace3046 100644
--- a/hw/xen/meson.build
+++ b/hw/xen/meson.build
@@ -18,7 +18,7 @@ if have_xen_pci_passthrough
'xen_pt_msi.c',
))
else
- xen_specific_ss.add('xen_pt_stub.c')
+ xen_specific_ss.add(files('xen_pt_stub.c'))
endif
specific_ss.add_all(when: ['CONFIG_XEN', xen], if_true: xen_specific_ss)
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
2022-10-15 5:07 ` [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-19 14:53 ` Paul Durrant
2022-10-15 5:07 ` [PATCH v1 03/12] hw/i386/xen: rearrange xen_hvm_init_pc Vikram Garhwal
` (11 subsequent siblings)
13 siblings, 1 reply; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Michael S. Tsirkin,
Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
Eduardo Habkost, Stefano Stabellini, Anthony Perard,
Paul Durrant, open list:X86 Xen CPUs
xen-mapcache.c contains common functions which can be used for enabling Xen on
aarch64 with IOREQ handling. Moving it out from hw/i386/xen to hw/xen to make it
accessible for both aarch64 and x86.
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
hw/i386/meson.build | 1 +
hw/i386/xen/meson.build | 1 -
hw/i386/xen/trace-events | 5 -----
hw/xen/meson.build | 4 ++++
hw/xen/trace-events | 5 +++++
hw/{i386 => }/xen/xen-mapcache.c | 0
6 files changed, 10 insertions(+), 6 deletions(-)
rename hw/{i386 => }/xen/xen-mapcache.c (100%)
diff --git a/hw/i386/meson.build b/hw/i386/meson.build
index 213e2e82b3..cfdbfdcbcb 100644
--- a/hw/i386/meson.build
+++ b/hw/i386/meson.build
@@ -33,5 +33,6 @@ subdir('kvm')
subdir('xen')
i386_ss.add_all(xenpv_ss)
+i386_ss.add_all(xen_ss)
hw_arch += {'i386': i386_ss}
diff --git a/hw/i386/xen/meson.build b/hw/i386/xen/meson.build
index be84130300..2fcc46e6ca 100644
--- a/hw/i386/xen/meson.build
+++ b/hw/i386/xen/meson.build
@@ -1,6 +1,5 @@
i386_ss.add(when: 'CONFIG_XEN', if_true: files(
'xen-hvm.c',
- 'xen-mapcache.c',
'xen_apic.c',
'xen_platform.c',
'xen_pvdevice.c',
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index 5d6be61090..a0c89d91c4 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -21,8 +21,3 @@ xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
cpu_ioreq_config_read(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
-# xen-mapcache.c
-xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
-xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
-xen_map_cache_return(void* ptr) "%p"
-
diff --git a/hw/xen/meson.build b/hw/xen/meson.build
index ae0ace3046..19d0637c46 100644
--- a/hw/xen/meson.build
+++ b/hw/xen/meson.build
@@ -22,3 +22,7 @@ else
endif
specific_ss.add_all(when: ['CONFIG_XEN', xen], if_true: xen_specific_ss)
+
+xen_ss = ss.source_set()
+
+xen_ss.add(when: 'CONFIG_XEN', if_true: files('xen-mapcache.c'))
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 3da3fd8348..2c8f238f42 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -41,3 +41,8 @@ xs_node_vprintf(char *path, char *value) "%s %s"
xs_node_vscanf(char *path, char *value) "%s %s"
xs_node_watch(char *path) "%s"
xs_node_unwatch(char *path) "%s"
+
+# xen-mapcache.c
+xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
+xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
+xen_map_cache_return(void* ptr) "%p"
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
similarity index 100%
rename from hw/i386/xen/xen-mapcache.c
rename to hw/xen/xen-mapcache.c
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 03/12] hw/i386/xen: rearrange xen_hvm_init_pc
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
2022-10-15 5:07 ` [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub Vikram Garhwal
2022-10-15 5:07 ` [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/ Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-19 14:59 ` Paul Durrant
2022-10-15 5:07 ` [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState Vikram Garhwal
` (10 subsequent siblings)
13 siblings, 1 reply; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, Paolo Bonzini, Richard Henderson,
Eduardo Habkost, Michael S. Tsirkin, Marcel Apfelbaum,
open list:X86 Xen CPUs
In preparation to moving most of xen-hvm code to an arch-neutral location,
move non IOREQ references to:
- xen_get_vmport_regs_pfn
- xen_suspend_notifier
- xen_wakeup_notifier
- xen_ram_init
towards the end of the xen_hvm_init_pc() function.
This is done to keep the common ioreq functions in one place which will be
moved to new function in next patch in order to make it common to both x86 and
aarch64 machines.
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
hw/i386/xen/xen-hvm.c | 49 ++++++++++++++++++++++---------------------
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index e4293d6d66..b27484ad22 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1416,12 +1416,6 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
state->exit.notify = xen_exit_notifier;
qemu_add_exit_notifier(&state->exit);
- state->suspend.notify = xen_suspend_notifier;
- qemu_register_suspend_notifier(&state->suspend);
-
- state->wakeup.notify = xen_wakeup_notifier;
- qemu_register_wakeup_notifier(&state->wakeup);
-
/*
* Register wake-up support in QMP query-current-machine API
*/
@@ -1432,23 +1426,6 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
goto err;
}
- rc = xen_get_vmport_regs_pfn(xen_xc, xen_domid, &ioreq_pfn);
- if (!rc) {
- DPRINTF("shared vmport page at pfn %lx\n", ioreq_pfn);
- state->shared_vmport_page =
- xenforeignmemory_map(xen_fmem, xen_domid, PROT_READ|PROT_WRITE,
- 1, &ioreq_pfn, NULL);
- if (state->shared_vmport_page == NULL) {
- error_report("map shared vmport IO page returned error %d handle=%p",
- errno, xen_xc);
- goto err;
- }
- } else if (rc != -ENOSYS) {
- error_report("get vmport regs pfn returned error %d, rc=%d",
- errno, rc);
- goto err;
- }
-
/* Note: cpus is empty at this point in init */
state->cpu_by_vcpu_id = g_new0(CPUState *, max_cpus);
@@ -1486,7 +1463,6 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
#else
xen_map_cache_init(NULL, state);
#endif
- xen_ram_init(pcms, ms->ram_size, ram_memory);
qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
@@ -1513,6 +1489,31 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
QLIST_INIT(&xen_physmap);
xen_read_physmap(state);
+ state->suspend.notify = xen_suspend_notifier;
+ qemu_register_suspend_notifier(&state->suspend);
+
+ state->wakeup.notify = xen_wakeup_notifier;
+ qemu_register_wakeup_notifier(&state->wakeup);
+
+ rc = xen_get_vmport_regs_pfn(xen_xc, xen_domid, &ioreq_pfn);
+ if (!rc) {
+ DPRINTF("shared vmport page at pfn %lx\n", ioreq_pfn);
+ state->shared_vmport_page =
+ xenforeignmemory_map(xen_fmem, xen_domid, PROT_READ|PROT_WRITE,
+ 1, &ioreq_pfn, NULL);
+ if (state->shared_vmport_page == NULL) {
+ error_report("map shared vmport IO page returned error %d handle=%p",
+ errno, xen_xc);
+ goto err;
+ }
+ } else if (rc != -ENOSYS) {
+ error_report("get vmport regs pfn returned error %d, rc=%d",
+ errno, rc);
+ goto err;
+ }
+
+ xen_ram_init(pcms, ms->ram_size, ram_memory);
+
/* Disable ACPI build because Xen handles it */
pcms->acpi_build_enabled = false;
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (2 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 03/12] hw/i386/xen: rearrange xen_hvm_init_pc Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-19 15:56 ` Paul Durrant
` (2 more replies)
2022-10-15 5:07 ` [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory Vikram Garhwal
` (9 subsequent siblings)
13 siblings, 3 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, Michael S. Tsirkin,
Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
Eduardo Habkost, open list:X86 Xen CPUs
From: Stefano Stabellini <stefano.stabellini@amd.com>
In preparation to moving most of xen-hvm code to an arch-neutral location, move:
- shared_vmport_page
- log_for_dirtybit
- dirty_bitmap
- suspend
- wakeup
out of XenIOState struct as these are only used on x86, especially the ones
related to dirty logging.
Updated XenIOState can be used for both aarch64 and x86.
Also, remove free_phys_offset as it was unused.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
---
hw/i386/xen/xen-hvm.c | 58 ++++++++++++++++++++-----------------------
1 file changed, 27 insertions(+), 31 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index b27484ad22..e169de16c4 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -73,6 +73,7 @@ struct shared_vmport_iopage {
};
typedef struct shared_vmport_iopage shared_vmport_iopage_t;
#endif
+static shared_vmport_iopage_t *shared_vmport_page;
static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
{
@@ -95,6 +96,11 @@ typedef struct XenPhysmap {
} XenPhysmap;
static QLIST_HEAD(, XenPhysmap) xen_physmap;
+static const XenPhysmap *log_for_dirtybit;
+/* Buffer used by xen_sync_dirty_bitmap */
+static unsigned long *dirty_bitmap;
+static Notifier suspend;
+static Notifier wakeup;
typedef struct XenPciDevice {
PCIDevice *pci_dev;
@@ -105,7 +111,6 @@ typedef struct XenPciDevice {
typedef struct XenIOState {
ioservid_t ioservid;
shared_iopage_t *shared_page;
- shared_vmport_iopage_t *shared_vmport_page;
buffered_iopage_t *buffered_io_page;
xenforeignmemory_resource_handle *fres;
QEMUTimer *buffered_io_timer;
@@ -125,14 +130,8 @@ typedef struct XenIOState {
MemoryListener io_listener;
QLIST_HEAD(, XenPciDevice) dev_list;
DeviceListener device_listener;
- hwaddr free_phys_offset;
- const XenPhysmap *log_for_dirtybit;
- /* Buffer used by xen_sync_dirty_bitmap */
- unsigned long *dirty_bitmap;
Notifier exit;
- Notifier suspend;
- Notifier wakeup;
} XenIOState;
/* Xen specific function for piix pci */
@@ -462,10 +461,10 @@ static int xen_remove_from_physmap(XenIOState *state,
}
QLIST_REMOVE(physmap, list);
- if (state->log_for_dirtybit == physmap) {
- state->log_for_dirtybit = NULL;
- g_free(state->dirty_bitmap);
- state->dirty_bitmap = NULL;
+ if (log_for_dirtybit == physmap) {
+ log_for_dirtybit = NULL;
+ g_free(dirty_bitmap);
+ dirty_bitmap = NULL;
}
g_free(physmap);
@@ -626,16 +625,16 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
return;
}
- if (state->log_for_dirtybit == NULL) {
- state->log_for_dirtybit = physmap;
- state->dirty_bitmap = g_new(unsigned long, bitmap_size);
- } else if (state->log_for_dirtybit != physmap) {
+ if (log_for_dirtybit == NULL) {
+ log_for_dirtybit = physmap;
+ dirty_bitmap = g_new(unsigned long, bitmap_size);
+ } else if (log_for_dirtybit != physmap) {
/* Only one range for dirty bitmap can be tracked. */
return;
}
rc = xen_track_dirty_vram(xen_domid, start_addr >> TARGET_PAGE_BITS,
- npages, state->dirty_bitmap);
+ npages, dirty_bitmap);
if (rc < 0) {
#ifndef ENODATA
#define ENODATA ENOENT
@@ -650,7 +649,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
}
for (i = 0; i < bitmap_size; i++) {
- unsigned long map = state->dirty_bitmap[i];
+ unsigned long map = dirty_bitmap[i];
while (map != 0) {
j = ctzl(map);
map &= ~(1ul << j);
@@ -676,12 +675,10 @@ static void xen_log_start(MemoryListener *listener,
static void xen_log_stop(MemoryListener *listener, MemoryRegionSection *section,
int old, int new)
{
- XenIOState *state = container_of(listener, XenIOState, memory_listener);
-
if (old & ~new & (1 << DIRTY_MEMORY_VGA)) {
- state->log_for_dirtybit = NULL;
- g_free(state->dirty_bitmap);
- state->dirty_bitmap = NULL;
+ log_for_dirtybit = NULL;
+ g_free(dirty_bitmap);
+ dirty_bitmap = NULL;
/* Disable dirty bit tracking */
xen_track_dirty_vram(xen_domid, 0, 0, NULL);
}
@@ -1021,9 +1018,9 @@ static void handle_vmport_ioreq(XenIOState *state, ioreq_t *req)
{
vmware_regs_t *vmport_regs;
- assert(state->shared_vmport_page);
+ assert(shared_vmport_page);
vmport_regs =
- &state->shared_vmport_page->vcpu_vmport_regs[state->send_vcpu];
+ &shared_vmport_page->vcpu_vmport_regs[state->send_vcpu];
QEMU_BUILD_BUG_ON(sizeof(*req) < sizeof(*vmport_regs));
current_cpu = state->cpu_by_vcpu_id[state->send_vcpu];
@@ -1468,7 +1465,6 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
state->memory_listener = xen_memory_listener;
memory_listener_register(&state->memory_listener, &address_space_memory);
- state->log_for_dirtybit = NULL;
state->io_listener = xen_io_listener;
memory_listener_register(&state->io_listener, &address_space_io);
@@ -1489,19 +1485,19 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
QLIST_INIT(&xen_physmap);
xen_read_physmap(state);
- state->suspend.notify = xen_suspend_notifier;
- qemu_register_suspend_notifier(&state->suspend);
+ suspend.notify = xen_suspend_notifier;
+ qemu_register_suspend_notifier(&suspend);
- state->wakeup.notify = xen_wakeup_notifier;
- qemu_register_wakeup_notifier(&state->wakeup);
+ wakeup.notify = xen_wakeup_notifier;
+ qemu_register_wakeup_notifier(&wakeup);
rc = xen_get_vmport_regs_pfn(xen_xc, xen_domid, &ioreq_pfn);
if (!rc) {
DPRINTF("shared vmport page at pfn %lx\n", ioreq_pfn);
- state->shared_vmport_page =
+ shared_vmport_page =
xenforeignmemory_map(xen_fmem, xen_domid, PROT_READ|PROT_WRITE,
1, &ioreq_pfn, NULL);
- if (state->shared_vmport_page == NULL) {
+ if (shared_vmport_page == NULL) {
error_report("map shared vmport IO page returned error %d handle=%p",
errno, xen_xc);
goto err;
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (3 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-19 16:09 ` Paul Durrant
2022-10-27 9:02 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c Vikram Garhwal
` (8 subsequent siblings)
13 siblings, 2 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, Michael S. Tsirkin,
Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
Eduardo Habkost, open list:X86 Xen CPUs
From: Stefano Stabellini <stefano.stabellini@amd.com>
In preparation to moving most of xen-hvm code to an arch-neutral location,
move the x86-specific portion of xen_set_memory to arch_xen_set_memory.
Also move handle_vmport_ioreq to arch_handle_ioreq.
NOTE: This patch breaks the build. Next patch fixes the build issue.
Reason behind creating this patch is because there is lot of new code addition
and pure code movement done for enabling Xen on ARM. Keeping the this patch
separate is done to make it easier to review.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
---
hw/i386/xen/xen-hvm.c | 97 ++++++++++++++++++++--------------
include/hw/i386/xen_arch_hvm.h | 10 ++++
include/hw/xen/arch_hvm.h | 3 ++
3 files changed, 70 insertions(+), 40 deletions(-)
create mode 100644 include/hw/i386/xen_arch_hvm.h
create mode 100644 include/hw/xen/arch_hvm.h
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index e169de16c4..3cd1808f9d 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -34,6 +34,7 @@
#include "trace.h"
#include <xen/hvm/ioreq.h>
+#include "hw/xen/arch_hvm.h"
#include <xen/hvm/e820.h>
//#define DEBUG_XEN_HVM
@@ -476,10 +477,6 @@ static void xen_set_memory(struct MemoryListener *listener,
bool add)
{
XenIOState *state = container_of(listener, XenIOState, memory_listener);
- hwaddr start_addr = section->offset_within_address_space;
- ram_addr_t size = int128_get64(section->size);
- bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA);
- hvmmem_type_t mem_type;
if (section->mr == &ram_memory) {
return;
@@ -492,38 +489,7 @@ static void xen_set_memory(struct MemoryListener *listener,
section);
}
}
-
- if (!memory_region_is_ram(section->mr)) {
- return;
- }
-
- if (log_dirty != add) {
- return;
- }
-
- trace_xen_client_set_memory(start_addr, size, log_dirty);
-
- start_addr &= TARGET_PAGE_MASK;
- size = TARGET_PAGE_ALIGN(size);
-
- if (add) {
- if (!memory_region_is_rom(section->mr)) {
- xen_add_to_physmap(state, start_addr, size,
- section->mr, section->offset_within_region);
- } else {
- mem_type = HVMMEM_ram_ro;
- if (xen_set_mem_type(xen_domid, mem_type,
- start_addr >> TARGET_PAGE_BITS,
- size >> TARGET_PAGE_BITS)) {
- DPRINTF("xen_set_mem_type error, addr: "TARGET_FMT_plx"\n",
- start_addr);
- }
- }
- } else {
- if (xen_remove_from_physmap(state, start_addr, size) < 0) {
- DPRINTF("physmapping does not exist at "TARGET_FMT_plx"\n", start_addr);
- }
- }
+ arch_xen_set_memory(state, section, add);
}
static void xen_region_add(MemoryListener *listener,
@@ -1051,9 +1017,6 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req)
case IOREQ_TYPE_COPY:
cpu_ioreq_move(req);
break;
- case IOREQ_TYPE_VMWARE_PORT:
- handle_vmport_ioreq(state, req);
- break;
case IOREQ_TYPE_TIMEOFFSET:
break;
case IOREQ_TYPE_INVALIDATE:
@@ -1063,7 +1026,7 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req)
cpu_ioreq_config(state, req);
break;
default:
- hw_error("Invalid ioreq type 0x%x\n", req->type);
+ arch_handle_ioreq(state, req);
}
if (req->dir == IOREQ_READ) {
trace_handle_ioreq_read(req, req->type, req->df, req->data_is_ptr,
@@ -1604,3 +1567,57 @@ void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
memory_global_dirty_log_stop(GLOBAL_DIRTY_MIGRATION);
}
}
+
+void arch_xen_set_memory(XenIOState *state, MemoryRegionSection *section,
+ bool add)
+{
+ hwaddr start_addr = section->offset_within_address_space;
+ ram_addr_t size = int128_get64(section->size);
+ bool log_dirty = memory_region_is_logging(section->mr, DIRTY_MEMORY_VGA);
+ hvmmem_type_t mem_type;
+
+ if (!memory_region_is_ram(section->mr)) {
+ return;
+ }
+
+ if (log_dirty != add) {
+ return;
+ }
+
+ trace_xen_client_set_memory(start_addr, size, log_dirty);
+
+ start_addr &= TARGET_PAGE_MASK;
+ size = TARGET_PAGE_ALIGN(size);
+
+ if (add) {
+ if (!memory_region_is_rom(section->mr)) {
+ xen_add_to_physmap(state, start_addr, size,
+ section->mr, section->offset_within_region);
+ } else {
+ mem_type = HVMMEM_ram_ro;
+ if (xen_set_mem_type(xen_domid, mem_type,
+ start_addr >> TARGET_PAGE_BITS,
+ size >> TARGET_PAGE_BITS)) {
+ DPRINTF("xen_set_mem_type error, addr: "TARGET_FMT_plx"\n",
+ start_addr);
+ }
+ }
+ } else {
+ if (xen_remove_from_physmap(state, start_addr, size) < 0) {
+ DPRINTF("physmapping does not exist at "TARGET_FMT_plx"\n", start_addr);
+ }
+ }
+}
+
+void arch_handle_ioreq(XenIOState *state, ioreq_t *req)
+{
+ switch (req->type) {
+ case IOREQ_TYPE_VMWARE_PORT:
+ handle_vmport_ioreq(state, req);
+ break;
+ default:
+ hw_error("Invalid ioreq type 0x%x\n", req->type);
+ }
+
+ return;
+}
diff --git a/include/hw/i386/xen_arch_hvm.h b/include/hw/i386/xen_arch_hvm.h
new file mode 100644
index 0000000000..1b2c71ba4f
--- /dev/null
+++ b/include/hw/i386/xen_arch_hvm.h
@@ -0,0 +1,10 @@
+#ifndef HW_XEN_ARCH_I386_HVM_H
+#define HW_XEN_ARCH_I386_HVM_H
+
+#include <xen/hvm/ioreq.h>
+
+void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
+void arch_xen_set_memory(XenIOState *state,
+ MemoryRegionSection *section,
+ bool add);
+#endif
diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
new file mode 100644
index 0000000000..26674648d8
--- /dev/null
+++ b/include/hw/xen/arch_hvm.h
@@ -0,0 +1,3 @@
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+#include "hw/i386/xen_arch_hvm.h"
+#endif
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (4 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-16 18:07 ` Julien Grall
2022-10-19 16:16 ` Paul Durrant
2022-10-15 5:07 ` [PATCH v1 07/12] include/hw/xen/xen_common: return error from xen_create_ioreq_server Vikram Garhwal
` (7 subsequent siblings)
13 siblings, 2 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, Michael S. Tsirkin,
Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
Eduardo Habkost, open list:X86 Xen CPUs
Extract common functionalities from hw/i386/xen/xen-hvm.c and move them to
hw/xen/xen-hvm-common.c. These common functions are useful for creating
an IOREQ server.
xen_hvm_init_pc() contains the arch independent code for creating and mapping
a IOREQ server, connecting memory and IO listeners, initializing a xen bus and
registering backends. Moved this common xen code to a new function
xen_register_ioreq() which can be used by both x86 and ARM machines.
Following functions are moved to hw/xen/xen-hvm-common.c:
xen_vcpu_eport(), xen_vcpu_ioreq(), xen_ram_alloc(), xen_set_memory(),
xen_region_add(), xen_region_del(), xen_io_add(), xen_io_del(),
xen_device_realize(), xen_device_unrealize(),
cpu_get_ioreq_from_shared_memory(), cpu_get_ioreq(), do_inp(), do_outp(),
rw_phys_req_item(), read_phys_req_item(), write_phys_req_item(),
cpu_ioreq_pio(), cpu_ioreq_move(), cpu_ioreq_config(), handle_ioreq(),
handle_buffered_iopage(), handle_buffered_io(), cpu_handle_ioreq(),
xen_main_loop_prepare(), xen_hvm_change_state_handler(),
xen_exit_notifier(), xen_map_ioreq_server(), destroy_hvm_domain() and
xen_shutdown_fatal_error()
Removed static type from below functions:
1. xen_region_add()
2. xen_region_del()
3. xen_io_add()
4. xen_io_del()
5. xen_device_realize()
6. xen_device_unrealize()
7. xen_hvm_change_state_handler()
8. cpu_ioreq_pio()
9. xen_exit_notifier()
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
hw/i386/xen/trace-events | 14 -
hw/i386/xen/xen-hvm.c | 930 +-------------------------------
hw/xen/meson.build | 5 +-
hw/xen/trace-events | 14 +
hw/xen/xen-hvm-common.c | 858 +++++++++++++++++++++++++++++
include/hw/i386/xen_arch_hvm.h | 1 +
include/hw/xen/xen-hvm-common.h | 97 ++++
7 files changed, 983 insertions(+), 936 deletions(-)
create mode 100644 hw/xen/xen-hvm-common.c
create mode 100644 include/hw/xen/xen-hvm-common.h
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index a0c89d91c4..5d0a8d6dcf 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -7,17 +7,3 @@ xen_platform_log(char *s) "xen platform: %s"
xen_pv_mmio_read(uint64_t addr) "WARNING: read from Xen PV Device MMIO space (address 0x%"PRIx64")"
xen_pv_mmio_write(uint64_t addr) "WARNING: write to Xen PV Device MMIO space (address 0x%"PRIx64")"
-# xen-hvm.c
-xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: 0x%lx, size 0x%lx"
-xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty) "0x%"PRIx64" size 0x%lx, log_dirty %i"
-handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p type=%d dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
-handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p read type=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
-handle_ioreq_write(void *req, uint32_t type, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p write type=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
-cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p pio dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
-cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) "I/O=%p pio read reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
-cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) "I/O=%p pio write reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
-cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
-xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
-cpu_ioreq_config_read(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
-cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
-
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 3cd1808f9d..0406f13b35 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -10,47 +10,20 @@
#include "qemu/osdep.h"
#include "qemu/units.h"
+#include "qapi/error.h"
+#include "qapi/qapi-commands-migration.h"
+#include "trace.h"
-#include "cpu.h"
-#include "hw/pci/pci.h"
-#include "hw/pci/pci_host.h"
#include "hw/i386/pc.h"
#include "hw/irq.h"
-#include "hw/hw.h"
#include "hw/i386/apic-msidef.h"
-#include "hw/xen/xen_common.h"
-#include "hw/xen/xen-legacy-backend.h"
-#include "hw/xen/xen-bus.h"
#include "hw/xen/xen-x86.h"
-#include "qapi/error.h"
-#include "qapi/qapi-commands-migration.h"
-#include "qemu/error-report.h"
-#include "qemu/main-loop.h"
#include "qemu/range.h"
-#include "sysemu/runstate.h"
-#include "sysemu/sysemu.h"
-#include "sysemu/xen.h"
-#include "sysemu/xen-mapcache.h"
-#include "trace.h"
-#include <xen/hvm/ioreq.h>
+#include "hw/xen/xen-hvm-common.h"
#include "hw/xen/arch_hvm.h"
#include <xen/hvm/e820.h>
-//#define DEBUG_XEN_HVM
-
-#ifdef DEBUG_XEN_HVM
-#define DPRINTF(fmt, ...) \
- do { fprintf(stderr, "xen: " fmt, ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF(fmt, ...) \
- do { } while (0)
-#endif
-
-static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
-static MemoryRegion *framebuffer;
-static bool xen_in_migration;
-
/* Compatibility with older version */
/* This allows QEMU to build on a system that has Xen 4.5 or earlier
@@ -76,26 +49,9 @@ typedef struct shared_vmport_iopage shared_vmport_iopage_t;
#endif
static shared_vmport_iopage_t *shared_vmport_page;
-static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
-{
- return shared_page->vcpu_ioreq[i].vp_eport;
-}
-static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
-{
- return &shared_page->vcpu_ioreq[vcpu];
-}
-
-#define BUFFER_IO_MAX_DELAY 100
-
-typedef struct XenPhysmap {
- hwaddr start_addr;
- ram_addr_t size;
- const char *name;
- hwaddr phys_offset;
-
- QLIST_ENTRY(XenPhysmap) list;
-} XenPhysmap;
-
+static MemoryRegion ram_640k, ram_lo, ram_hi;
+static MemoryRegion *framebuffer;
+static bool xen_in_migration;
static QLIST_HEAD(, XenPhysmap) xen_physmap;
static const XenPhysmap *log_for_dirtybit;
/* Buffer used by xen_sync_dirty_bitmap */
@@ -103,38 +59,6 @@ static unsigned long *dirty_bitmap;
static Notifier suspend;
static Notifier wakeup;
-typedef struct XenPciDevice {
- PCIDevice *pci_dev;
- uint32_t sbdf;
- QLIST_ENTRY(XenPciDevice) entry;
-} XenPciDevice;
-
-typedef struct XenIOState {
- ioservid_t ioservid;
- shared_iopage_t *shared_page;
- buffered_iopage_t *buffered_io_page;
- xenforeignmemory_resource_handle *fres;
- QEMUTimer *buffered_io_timer;
- CPUState **cpu_by_vcpu_id;
- /* the evtchn port for polling the notification, */
- evtchn_port_t *ioreq_local_port;
- /* evtchn remote and local ports for buffered io */
- evtchn_port_t bufioreq_remote_port;
- evtchn_port_t bufioreq_local_port;
- /* the evtchn fd for polling */
- xenevtchn_handle *xce_handle;
- /* which vcpu we are serving */
- int send_vcpu;
-
- struct xs_handle *xenstore;
- MemoryListener memory_listener;
- MemoryListener io_listener;
- QLIST_HEAD(, XenPciDevice) dev_list;
- DeviceListener device_listener;
-
- Notifier exit;
-} XenIOState;
-
/* Xen specific function for piix pci */
int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
@@ -247,42 +171,6 @@ static void xen_ram_init(PCMachineState *pcms,
}
}
-void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr,
- Error **errp)
-{
- unsigned long nr_pfn;
- xen_pfn_t *pfn_list;
- int i;
-
- if (runstate_check(RUN_STATE_INMIGRATE)) {
- /* RAM already populated in Xen */
- fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
- " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
- __func__, size, ram_addr);
- return;
- }
-
- if (mr == &ram_memory) {
- return;
- }
-
- trace_xen_ram_alloc(ram_addr, size);
-
- nr_pfn = size >> TARGET_PAGE_BITS;
- pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
-
- for (i = 0; i < nr_pfn; i++) {
- pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
- }
-
- if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
- error_setg(errp, "xen: failed to populate ram at " RAM_ADDR_FMT,
- ram_addr);
- }
-
- g_free(pfn_list);
-}
-
static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size)
{
XenPhysmap *physmap = NULL;
@@ -472,109 +360,6 @@ static int xen_remove_from_physmap(XenIOState *state,
return 0;
}
-static void xen_set_memory(struct MemoryListener *listener,
- MemoryRegionSection *section,
- bool add)
-{
- XenIOState *state = container_of(listener, XenIOState, memory_listener);
-
- if (section->mr == &ram_memory) {
- return;
- } else {
- if (add) {
- xen_map_memory_section(xen_domid, state->ioservid,
- section);
- } else {
- xen_unmap_memory_section(xen_domid, state->ioservid,
- section);
- }
- }
- arch_xen_set_memory(state, section, add);
-}
-
-static void xen_region_add(MemoryListener *listener,
- MemoryRegionSection *section)
-{
- memory_region_ref(section->mr);
- xen_set_memory(listener, section, true);
-}
-
-static void xen_region_del(MemoryListener *listener,
- MemoryRegionSection *section)
-{
- xen_set_memory(listener, section, false);
- memory_region_unref(section->mr);
-}
-
-static void xen_io_add(MemoryListener *listener,
- MemoryRegionSection *section)
-{
- XenIOState *state = container_of(listener, XenIOState, io_listener);
- MemoryRegion *mr = section->mr;
-
- if (mr->ops == &unassigned_io_ops) {
- return;
- }
-
- memory_region_ref(mr);
-
- xen_map_io_section(xen_domid, state->ioservid, section);
-}
-
-static void xen_io_del(MemoryListener *listener,
- MemoryRegionSection *section)
-{
- XenIOState *state = container_of(listener, XenIOState, io_listener);
- MemoryRegion *mr = section->mr;
-
- if (mr->ops == &unassigned_io_ops) {
- return;
- }
-
- xen_unmap_io_section(xen_domid, state->ioservid, section);
-
- memory_region_unref(mr);
-}
-
-static void xen_device_realize(DeviceListener *listener,
- DeviceState *dev)
-{
- XenIOState *state = container_of(listener, XenIOState, device_listener);
-
- if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
- PCIDevice *pci_dev = PCI_DEVICE(dev);
- XenPciDevice *xendev = g_new(XenPciDevice, 1);
-
- xendev->pci_dev = pci_dev;
- xendev->sbdf = PCI_BUILD_BDF(pci_dev_bus_num(pci_dev),
- pci_dev->devfn);
- QLIST_INSERT_HEAD(&state->dev_list, xendev, entry);
-
- xen_map_pcidev(xen_domid, state->ioservid, pci_dev);
- }
-}
-
-static void xen_device_unrealize(DeviceListener *listener,
- DeviceState *dev)
-{
- XenIOState *state = container_of(listener, XenIOState, device_listener);
-
- if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
- PCIDevice *pci_dev = PCI_DEVICE(dev);
- XenPciDevice *xendev, *next;
-
- xen_unmap_pcidev(xen_domid, state->ioservid, pci_dev);
-
- QLIST_FOREACH_SAFE(xendev, &state->dev_list, entry, next) {
- if (xendev->pci_dev == pci_dev) {
- QLIST_REMOVE(xendev, entry);
- g_free(xendev);
- break;
- }
- }
- }
-}
-
static void xen_sync_dirty_bitmap(XenIOState *state,
hwaddr start_addr,
ram_addr_t size)
@@ -682,277 +467,6 @@ static MemoryListener xen_memory_listener = {
.priority = 10,
};
-static MemoryListener xen_io_listener = {
- .name = "xen-io",
- .region_add = xen_io_add,
- .region_del = xen_io_del,
- .priority = 10,
-};
-
-static DeviceListener xen_device_listener = {
- .realize = xen_device_realize,
- .unrealize = xen_device_unrealize,
-};
-
-/* get the ioreq packets from share mem */
-static ioreq_t *cpu_get_ioreq_from_shared_memory(XenIOState *state, int vcpu)
-{
- ioreq_t *req = xen_vcpu_ioreq(state->shared_page, vcpu);
-
- if (req->state != STATE_IOREQ_READY) {
- DPRINTF("I/O request not ready: "
- "%x, ptr: %x, port: %"PRIx64", "
- "data: %"PRIx64", count: %u, size: %u\n",
- req->state, req->data_is_ptr, req->addr,
- req->data, req->count, req->size);
- return NULL;
- }
-
- xen_rmb(); /* see IOREQ_READY /then/ read contents of ioreq */
-
- req->state = STATE_IOREQ_INPROCESS;
- return req;
-}
-
-/* use poll to get the port notification */
-/* ioreq_vec--out,the */
-/* retval--the number of ioreq packet */
-static ioreq_t *cpu_get_ioreq(XenIOState *state)
-{
- MachineState *ms = MACHINE(qdev_get_machine());
- unsigned int max_cpus = ms->smp.max_cpus;
- int i;
- evtchn_port_t port;
-
- port = xenevtchn_pending(state->xce_handle);
- if (port == state->bufioreq_local_port) {
- timer_mod(state->buffered_io_timer,
- BUFFER_IO_MAX_DELAY + qemu_clock_get_ms(QEMU_CLOCK_REALTIME));
- return NULL;
- }
-
- if (port != -1) {
- for (i = 0; i < max_cpus; i++) {
- if (state->ioreq_local_port[i] == port) {
- break;
- }
- }
-
- if (i == max_cpus) {
- hw_error("Fatal error while trying to get io event!\n");
- }
-
- /* unmask the wanted port again */
- xenevtchn_unmask(state->xce_handle, port);
-
- /* get the io packet from shared memory */
- state->send_vcpu = i;
- return cpu_get_ioreq_from_shared_memory(state, i);
- }
-
- /* read error or read nothing */
- return NULL;
-}
-
-static uint32_t do_inp(uint32_t addr, unsigned long size)
-{
- switch (size) {
- case 1:
- return cpu_inb(addr);
- case 2:
- return cpu_inw(addr);
- case 4:
- return cpu_inl(addr);
- default:
- hw_error("inp: bad size: %04x %lx", addr, size);
- }
-}
-
-static void do_outp(uint32_t addr,
- unsigned long size, uint32_t val)
-{
- switch (size) {
- case 1:
- return cpu_outb(addr, val);
- case 2:
- return cpu_outw(addr, val);
- case 4:
- return cpu_outl(addr, val);
- default:
- hw_error("outp: bad size: %04x %lx", addr, size);
- }
-}
-
-/*
- * Helper functions which read/write an object from/to physical guest
- * memory, as part of the implementation of an ioreq.
- *
- * Equivalent to
- * cpu_physical_memory_rw(addr + (req->df ? -1 : +1) * req->size * i,
- * val, req->size, 0/1)
- * except without the integer overflow problems.
- */
-static void rw_phys_req_item(hwaddr addr,
- ioreq_t *req, uint32_t i, void *val, int rw)
-{
- /* Do everything unsigned so overflow just results in a truncated result
- * and accesses to undesired parts of guest memory, which is up
- * to the guest */
- hwaddr offset = (hwaddr)req->size * i;
- if (req->df) {
- addr -= offset;
- } else {
- addr += offset;
- }
- cpu_physical_memory_rw(addr, val, req->size, rw);
-}
-
-static inline void read_phys_req_item(hwaddr addr,
- ioreq_t *req, uint32_t i, void *val)
-{
- rw_phys_req_item(addr, req, i, val, 0);
-}
-static inline void write_phys_req_item(hwaddr addr,
- ioreq_t *req, uint32_t i, void *val)
-{
- rw_phys_req_item(addr, req, i, val, 1);
-}
-
-
-static void cpu_ioreq_pio(ioreq_t *req)
-{
- uint32_t i;
-
- trace_cpu_ioreq_pio(req, req->dir, req->df, req->data_is_ptr, req->addr,
- req->data, req->count, req->size);
-
- if (req->size > sizeof(uint32_t)) {
- hw_error("PIO: bad size (%u)", req->size);
- }
-
- if (req->dir == IOREQ_READ) {
- if (!req->data_is_ptr) {
- req->data = do_inp(req->addr, req->size);
- trace_cpu_ioreq_pio_read_reg(req, req->data, req->addr,
- req->size);
- } else {
- uint32_t tmp;
-
- for (i = 0; i < req->count; i++) {
- tmp = do_inp(req->addr, req->size);
- write_phys_req_item(req->data, req, i, &tmp);
- }
- }
- } else if (req->dir == IOREQ_WRITE) {
- if (!req->data_is_ptr) {
- trace_cpu_ioreq_pio_write_reg(req, req->data, req->addr,
- req->size);
- do_outp(req->addr, req->size, req->data);
- } else {
- for (i = 0; i < req->count; i++) {
- uint32_t tmp = 0;
-
- read_phys_req_item(req->data, req, i, &tmp);
- do_outp(req->addr, req->size, tmp);
- }
- }
- }
-}
-
-static void cpu_ioreq_move(ioreq_t *req)
-{
- uint32_t i;
-
- trace_cpu_ioreq_move(req, req->dir, req->df, req->data_is_ptr, req->addr,
- req->data, req->count, req->size);
-
- if (req->size > sizeof(req->data)) {
- hw_error("MMIO: bad size (%u)", req->size);
- }
-
- if (!req->data_is_ptr) {
- if (req->dir == IOREQ_READ) {
- for (i = 0; i < req->count; i++) {
- read_phys_req_item(req->addr, req, i, &req->data);
- }
- } else if (req->dir == IOREQ_WRITE) {
- for (i = 0; i < req->count; i++) {
- write_phys_req_item(req->addr, req, i, &req->data);
- }
- }
- } else {
- uint64_t tmp;
-
- if (req->dir == IOREQ_READ) {
- for (i = 0; i < req->count; i++) {
- read_phys_req_item(req->addr, req, i, &tmp);
- write_phys_req_item(req->data, req, i, &tmp);
- }
- } else if (req->dir == IOREQ_WRITE) {
- for (i = 0; i < req->count; i++) {
- read_phys_req_item(req->data, req, i, &tmp);
- write_phys_req_item(req->addr, req, i, &tmp);
- }
- }
- }
-}
-
-static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
-{
- uint32_t sbdf = req->addr >> 32;
- uint32_t reg = req->addr;
- XenPciDevice *xendev;
-
- if (req->size != sizeof(uint8_t) && req->size != sizeof(uint16_t) &&
- req->size != sizeof(uint32_t)) {
- hw_error("PCI config access: bad size (%u)", req->size);
- }
-
- if (req->count != 1) {
- hw_error("PCI config access: bad count (%u)", req->count);
- }
-
- QLIST_FOREACH(xendev, &state->dev_list, entry) {
- if (xendev->sbdf != sbdf) {
- continue;
- }
-
- if (!req->data_is_ptr) {
- if (req->dir == IOREQ_READ) {
- req->data = pci_host_config_read_common(
- xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
- req->size);
- trace_cpu_ioreq_config_read(req, xendev->sbdf, reg,
- req->size, req->data);
- } else if (req->dir == IOREQ_WRITE) {
- trace_cpu_ioreq_config_write(req, xendev->sbdf, reg,
- req->size, req->data);
- pci_host_config_write_common(
- xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
- req->data, req->size);
- }
- } else {
- uint32_t tmp;
-
- if (req->dir == IOREQ_READ) {
- tmp = pci_host_config_read_common(
- xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
- req->size);
- trace_cpu_ioreq_config_read(req, xendev->sbdf, reg,
- req->size, tmp);
- write_phys_req_item(req->data, req, 0, &tmp);
- } else if (req->dir == IOREQ_WRITE) {
- read_phys_req_item(req->data, req, 0, &tmp);
- trace_cpu_ioreq_config_write(req, xendev->sbdf, reg,
- req->size, tmp);
- pci_host_config_write_common(
- xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
- tmp, req->size);
- }
- }
- }
-}
-
static void regs_to_cpu(vmware_regs_t *vmport_regs, ioreq_t *req)
{
X86CPU *cpu;
@@ -996,223 +510,6 @@ static void handle_vmport_ioreq(XenIOState *state, ioreq_t *req)
current_cpu = NULL;
}
-static void handle_ioreq(XenIOState *state, ioreq_t *req)
-{
- trace_handle_ioreq(req, req->type, req->dir, req->df, req->data_is_ptr,
- req->addr, req->data, req->count, req->size);
-
- if (!req->data_is_ptr && (req->dir == IOREQ_WRITE) &&
- (req->size < sizeof (target_ulong))) {
- req->data &= ((target_ulong) 1 << (8 * req->size)) - 1;
- }
-
- if (req->dir == IOREQ_WRITE)
- trace_handle_ioreq_write(req, req->type, req->df, req->data_is_ptr,
- req->addr, req->data, req->count, req->size);
-
- switch (req->type) {
- case IOREQ_TYPE_PIO:
- cpu_ioreq_pio(req);
- break;
- case IOREQ_TYPE_COPY:
- cpu_ioreq_move(req);
- break;
- case IOREQ_TYPE_TIMEOFFSET:
- break;
- case IOREQ_TYPE_INVALIDATE:
- xen_invalidate_map_cache();
- break;
- case IOREQ_TYPE_PCI_CONFIG:
- cpu_ioreq_config(state, req);
- break;
- default:
- arch_handle_ioreq(state, req);
- }
- if (req->dir == IOREQ_READ) {
- trace_handle_ioreq_read(req, req->type, req->df, req->data_is_ptr,
- req->addr, req->data, req->count, req->size);
- }
-}
-
-static bool handle_buffered_iopage(XenIOState *state)
-{
- buffered_iopage_t *buf_page = state->buffered_io_page;
- buf_ioreq_t *buf_req = NULL;
- bool handled_ioreq = false;
- ioreq_t req;
- int qw;
-
- if (!buf_page) {
- return 0;
- }
-
- memset(&req, 0x00, sizeof(req));
- req.state = STATE_IOREQ_READY;
- req.count = 1;
- req.dir = IOREQ_WRITE;
-
- for (;;) {
- uint32_t rdptr = buf_page->read_pointer, wrptr;
-
- xen_rmb();
- wrptr = buf_page->write_pointer;
- xen_rmb();
- if (rdptr != buf_page->read_pointer) {
- continue;
- }
- if (rdptr == wrptr) {
- break;
- }
- buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
- req.size = 1U << buf_req->size;
- req.addr = buf_req->addr;
- req.data = buf_req->data;
- req.type = buf_req->type;
- xen_rmb();
- qw = (req.size == 8);
- if (qw) {
- if (rdptr + 1 == wrptr) {
- hw_error("Incomplete quad word buffered ioreq");
- }
- buf_req = &buf_page->buf_ioreq[(rdptr + 1) %
- IOREQ_BUFFER_SLOT_NUM];
- req.data |= ((uint64_t)buf_req->data) << 32;
- xen_rmb();
- }
-
- handle_ioreq(state, &req);
-
- /* Only req.data may get updated by handle_ioreq(), albeit even that
- * should not happen as such data would never make it to the guest (we
- * can only usefully see writes here after all).
- */
- assert(req.state == STATE_IOREQ_READY);
- assert(req.count == 1);
- assert(req.dir == IOREQ_WRITE);
- assert(!req.data_is_ptr);
-
- qatomic_add(&buf_page->read_pointer, qw + 1);
- handled_ioreq = true;
- }
-
- return handled_ioreq;
-}
-
-static void handle_buffered_io(void *opaque)
-{
- XenIOState *state = opaque;
-
- if (handle_buffered_iopage(state)) {
- timer_mod(state->buffered_io_timer,
- BUFFER_IO_MAX_DELAY + qemu_clock_get_ms(QEMU_CLOCK_REALTIME));
- } else {
- timer_del(state->buffered_io_timer);
- xenevtchn_unmask(state->xce_handle, state->bufioreq_local_port);
- }
-}
-
-static void cpu_handle_ioreq(void *opaque)
-{
- XenIOState *state = opaque;
- ioreq_t *req = cpu_get_ioreq(state);
-
- handle_buffered_iopage(state);
- if (req) {
- ioreq_t copy = *req;
-
- xen_rmb();
- handle_ioreq(state, ©);
- req->data = copy.data;
-
- if (req->state != STATE_IOREQ_INPROCESS) {
- fprintf(stderr, "Badness in I/O request ... not in service?!: "
- "%x, ptr: %x, port: %"PRIx64", "
- "data: %"PRIx64", count: %u, size: %u, type: %u\n",
- req->state, req->data_is_ptr, req->addr,
- req->data, req->count, req->size, req->type);
- destroy_hvm_domain(false);
- return;
- }
-
- xen_wmb(); /* Update ioreq contents /then/ update state. */
-
- /*
- * We do this before we send the response so that the tools
- * have the opportunity to pick up on the reset before the
- * guest resumes and does a hlt with interrupts disabled which
- * causes Xen to powerdown the domain.
- */
- if (runstate_is_running()) {
- ShutdownCause request;
-
- if (qemu_shutdown_requested_get()) {
- destroy_hvm_domain(false);
- }
- request = qemu_reset_requested_get();
- if (request) {
- qemu_system_reset(request);
- destroy_hvm_domain(true);
- }
- }
-
- req->state = STATE_IORESP_READY;
- xenevtchn_notify(state->xce_handle,
- state->ioreq_local_port[state->send_vcpu]);
- }
-}
-
-static void xen_main_loop_prepare(XenIOState *state)
-{
- int evtchn_fd = -1;
-
- if (state->xce_handle != NULL) {
- evtchn_fd = xenevtchn_fd(state->xce_handle);
- }
-
- state->buffered_io_timer = timer_new_ms(QEMU_CLOCK_REALTIME, handle_buffered_io,
- state);
-
- if (evtchn_fd != -1) {
- CPUState *cpu_state;
-
- DPRINTF("%s: Init cpu_by_vcpu_id\n", __func__);
- CPU_FOREACH(cpu_state) {
- DPRINTF("%s: cpu_by_vcpu_id[%d]=%p\n",
- __func__, cpu_state->cpu_index, cpu_state);
- state->cpu_by_vcpu_id[cpu_state->cpu_index] = cpu_state;
- }
- qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
- }
-}
-
-
-static void xen_hvm_change_state_handler(void *opaque, bool running,
- RunState rstate)
-{
- XenIOState *state = opaque;
-
- if (running) {
- xen_main_loop_prepare(state);
- }
-
- xen_set_ioreq_server_state(xen_domid,
- state->ioservid,
- (rstate == RUN_STATE_RUNNING));
-}
-
-static void xen_exit_notifier(Notifier *n, void *data)
-{
- XenIOState *state = container_of(n, XenIOState, exit);
-
- xen_destroy_ioreq_server(xen_domid, state->ioservid);
- if (state->fres != NULL) {
- xenforeignmemory_unmap_resource(xen_fmem, state->fres);
- }
-
- xenevtchn_close(state->xce_handle);
- xs_daemon_close(state->xenstore);
-}
-
#ifdef XEN_COMPAT_PHYSMAP
static void xen_read_physmap(XenIOState *state)
{
@@ -1272,178 +569,17 @@ static void xen_wakeup_notifier(Notifier *notifier, void *data)
xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0);
}
-static int xen_map_ioreq_server(XenIOState *state)
-{
- void *addr = NULL;
- xen_pfn_t ioreq_pfn;
- xen_pfn_t bufioreq_pfn;
- evtchn_port_t bufioreq_evtchn;
- int rc;
-
- /*
- * Attempt to map using the resource API and fall back to normal
- * foreign mapping if this is not supported.
- */
- QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_bufioreq != 0);
- QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_ioreq(0) != 1);
- state->fres = xenforeignmemory_map_resource(xen_fmem, xen_domid,
- XENMEM_resource_ioreq_server,
- state->ioservid, 0, 2,
- &addr,
- PROT_READ | PROT_WRITE, 0);
- if (state->fres != NULL) {
- trace_xen_map_resource_ioreq(state->ioservid, addr);
- state->buffered_io_page = addr;
- state->shared_page = addr + TARGET_PAGE_SIZE;
- } else if (errno != EOPNOTSUPP) {
- error_report("failed to map ioreq server resources: error %d handle=%p",
- errno, xen_xc);
- return -1;
- }
-
- rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
- (state->shared_page == NULL) ?
- &ioreq_pfn : NULL,
- (state->buffered_io_page == NULL) ?
- &bufioreq_pfn : NULL,
- &bufioreq_evtchn);
- if (rc < 0) {
- error_report("failed to get ioreq server info: error %d handle=%p",
- errno, xen_xc);
- return rc;
- }
-
- if (state->shared_page == NULL) {
- DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
-
- state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
- PROT_READ | PROT_WRITE,
- 1, &ioreq_pfn, NULL);
- if (state->shared_page == NULL) {
- error_report("map shared IO page returned error %d handle=%p",
- errno, xen_xc);
- }
- }
-
- if (state->buffered_io_page == NULL) {
- DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
-
- state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
- PROT_READ | PROT_WRITE,
- 1, &bufioreq_pfn,
- NULL);
- if (state->buffered_io_page == NULL) {
- error_report("map buffered IO page returned error %d", errno);
- return -1;
- }
- }
-
- if (state->shared_page == NULL || state->buffered_io_page == NULL) {
- return -1;
- }
-
- DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-
- state->bufioreq_remote_port = bufioreq_evtchn;
-
- return 0;
-}
-
void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
{
MachineState *ms = MACHINE(pcms);
unsigned int max_cpus = ms->smp.max_cpus;
- int i, rc;
+ int rc;
xen_pfn_t ioreq_pfn;
XenIOState *state;
state = g_new0(XenIOState, 1);
- state->xce_handle = xenevtchn_open(NULL, 0);
- if (state->xce_handle == NULL) {
- perror("xen: event channel open");
- goto err;
- }
-
- state->xenstore = xs_daemon_open();
- if (state->xenstore == NULL) {
- perror("xen: xenstore open");
- goto err;
- }
-
- xen_create_ioreq_server(xen_domid, &state->ioservid);
-
- state->exit.notify = xen_exit_notifier;
- qemu_add_exit_notifier(&state->exit);
-
- /*
- * Register wake-up support in QMP query-current-machine API
- */
- qemu_register_wakeup_support();
-
- rc = xen_map_ioreq_server(state);
- if (rc < 0) {
- goto err;
- }
-
- /* Note: cpus is empty at this point in init */
- state->cpu_by_vcpu_id = g_new0(CPUState *, max_cpus);
-
- rc = xen_set_ioreq_server_state(xen_domid, state->ioservid, true);
- if (rc < 0) {
- error_report("failed to enable ioreq server info: error %d handle=%p",
- errno, xen_xc);
- goto err;
- }
-
- state->ioreq_local_port = g_new0(evtchn_port_t, max_cpus);
-
- /* FIXME: how about if we overflow the page here? */
- for (i = 0; i < max_cpus; i++) {
- rc = xenevtchn_bind_interdomain(state->xce_handle, xen_domid,
- xen_vcpu_eport(state->shared_page, i));
- if (rc == -1) {
- error_report("shared evtchn %d bind error %d", i, errno);
- goto err;
- }
- state->ioreq_local_port[i] = rc;
- }
-
- rc = xenevtchn_bind_interdomain(state->xce_handle, xen_domid,
- state->bufioreq_remote_port);
- if (rc == -1) {
- error_report("buffered evtchn bind error %d", errno);
- goto err;
- }
- state->bufioreq_local_port = rc;
-
- /* Init RAM management */
-#ifdef XEN_COMPAT_PHYSMAP
- xen_map_cache_init(xen_phys_offset_to_gaddr, state);
-#else
- xen_map_cache_init(NULL, state);
-#endif
-
- qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
-
- state->memory_listener = xen_memory_listener;
- memory_listener_register(&state->memory_listener, &address_space_memory);
-
- state->io_listener = xen_io_listener;
- memory_listener_register(&state->io_listener, &address_space_io);
-
- state->device_listener = xen_device_listener;
- QLIST_INIT(&state->dev_list);
- device_listener_register(&state->device_listener);
-
- xen_bus_init();
-
- /* Initialize backend core & drivers */
- if (xen_be_init() != 0) {
- error_report("xen backend core setup failed");
- goto err;
- }
- xen_be_register_common();
+ xen_register_ioreq(state, max_cpus, xen_memory_listener);
QLIST_INIT(&xen_physmap);
xen_read_physmap(state);
@@ -1483,59 +619,11 @@ err:
exit(1);
}
-void destroy_hvm_domain(bool reboot)
-{
- xc_interface *xc_handle;
- int sts;
- int rc;
-
- unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
-
- if (xen_dmod) {
- rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
- if (!rc) {
- return;
- }
- if (errno != ENOTTY /* old Xen */) {
- perror("xendevicemodel_shutdown failed");
- }
- /* well, try the old thing then */
- }
-
- xc_handle = xc_interface_open(0, 0, 0);
- if (xc_handle == NULL) {
- fprintf(stderr, "Cannot acquire xenctrl handle\n");
- } else {
- sts = xc_domain_shutdown(xc_handle, xen_domid, reason);
- if (sts != 0) {
- fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
- "sts %d, %s\n", reboot ? "reboot" : "poweroff",
- sts, strerror(errno));
- } else {
- fprintf(stderr, "Issued domain %d %s\n", xen_domid,
- reboot ? "reboot" : "poweroff");
- }
- xc_interface_close(xc_handle);
- }
-}
-
void xen_register_framebuffer(MemoryRegion *mr)
{
framebuffer = mr;
}
-void xen_shutdown_fatal_error(const char *fmt, ...)
-{
- va_list ap;
-
- va_start(ap, fmt);
- vfprintf(stderr, fmt, ap);
- va_end(ap);
- fprintf(stderr, "Will destroy the domain.\n");
- /* destroy the domain */
- qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_ERROR);
-}
-
void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
{
if (unlikely(xen_in_migration)) {
diff --git a/hw/xen/meson.build b/hw/xen/meson.build
index 19d0637c46..008e036d63 100644
--- a/hw/xen/meson.build
+++ b/hw/xen/meson.build
@@ -25,4 +25,7 @@ specific_ss.add_all(when: ['CONFIG_XEN', xen], if_true: xen_specific_ss)
xen_ss = ss.source_set()
-xen_ss.add(when: 'CONFIG_XEN', if_true: files('xen-mapcache.c'))
+xen_ss.add(when: 'CONFIG_XEN', if_true: files(
+ 'xen-mapcache.c',
+ 'xen-hvm-common.c',
+))
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 2c8f238f42..02ca1183da 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -42,6 +42,20 @@ xs_node_vscanf(char *path, char *value) "%s %s"
xs_node_watch(char *path) "%s"
xs_node_unwatch(char *path) "%s"
+# xen-hvm.c
+xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: 0x%lx, size 0x%lx"
+xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty) "0x%"PRIx64" size 0x%lx, log_dirty %i"
+handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p type=%d dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p read type=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+handle_ioreq_write(void *req, uint32_t type, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p write type=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p pio dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) "I/O=%p pio read reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
+cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) "I/O=%p pio write reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
+cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
+cpu_ioreq_config_read(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
+cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
+
# xen-mapcache.c
xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
new file mode 100644
index 0000000000..f848f9e625
--- /dev/null
+++ b/hw/xen/xen-hvm-common.c
@@ -0,0 +1,858 @@
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "trace.h"
+
+#include "hw/pci/pci_host.h"
+#include "hw/xen/xen-hvm-common.h"
+#include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-bus.h"
+#include "hw/boards.h"
+#include "hw/xen/arch_hvm.h"
+
+MemoryRegion ram_memory;
+
+void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr,
+ Error **errp)
+{
+ unsigned long nr_pfn;
+ xen_pfn_t *pfn_list;
+ int i;
+
+ if (runstate_check(RUN_STATE_INMIGRATE)) {
+ /* RAM already populated in Xen */
+ fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
+ " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+ __func__, size, ram_addr);
+ return;
+ }
+
+ if (mr == &ram_memory) {
+ return;
+ }
+
+ trace_xen_ram_alloc(ram_addr, size);
+
+ nr_pfn = size >> TARGET_PAGE_BITS;
+ pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
+
+ for (i = 0; i < nr_pfn; i++) {
+ pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
+ }
+
+ if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, pfn_list)) {
+ error_setg(errp, "xen: failed to populate ram at " RAM_ADDR_FMT,
+ ram_addr);
+ }
+
+ g_free(pfn_list);
+}
+
+
+static void xen_set_memory(struct MemoryListener *listener,
+ MemoryRegionSection *section,
+ bool add)
+{
+ XenIOState *state = container_of(listener, XenIOState, memory_listener);
+
+ if (section->mr == &ram_memory) {
+ return;
+ } else {
+ if (add) {
+ xen_map_memory_section(xen_domid, state->ioservid,
+ section);
+ } else {
+ xen_unmap_memory_section(xen_domid, state->ioservid,
+ section);
+ }
+ }
+ arch_xen_set_memory(state, section, add);
+}
+
+void xen_region_add(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+ memory_region_ref(section->mr);
+ xen_set_memory(listener, section, true);
+}
+
+void xen_region_del(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+ xen_set_memory(listener, section, false);
+ memory_region_unref(section->mr);
+}
+
+void xen_io_add(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+ XenIOState *state = container_of(listener, XenIOState, io_listener);
+ MemoryRegion *mr = section->mr;
+
+ if (mr->ops == &unassigned_io_ops) {
+ return;
+ }
+
+ memory_region_ref(mr);
+
+ xen_map_io_section(xen_domid, state->ioservid, section);
+}
+
+void xen_io_del(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+ XenIOState *state = container_of(listener, XenIOState, io_listener);
+ MemoryRegion *mr = section->mr;
+
+ if (mr->ops == &unassigned_io_ops) {
+ return;
+ }
+
+ xen_unmap_io_section(xen_domid, state->ioservid, section);
+
+ memory_region_unref(mr);
+}
+
+void xen_device_realize(DeviceListener *listener,
+ DeviceState *dev)
+{
+ XenIOState *state = container_of(listener, XenIOState, device_listener);
+
+ if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+ PCIDevice *pci_dev = PCI_DEVICE(dev);
+ XenPciDevice *xendev = g_new(XenPciDevice, 1);
+
+ xendev->pci_dev = pci_dev;
+ xendev->sbdf = PCI_BUILD_BDF(pci_dev_bus_num(pci_dev),
+ pci_dev->devfn);
+ QLIST_INSERT_HEAD(&state->dev_list, xendev, entry);
+
+ xen_map_pcidev(xen_domid, state->ioservid, pci_dev);
+ }
+}
+
+void xen_device_unrealize(DeviceListener *listener,
+ DeviceState *dev)
+{
+ XenIOState *state = container_of(listener, XenIOState, device_listener);
+
+ if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+ PCIDevice *pci_dev = PCI_DEVICE(dev);
+ XenPciDevice *xendev, *next;
+
+ xen_unmap_pcidev(xen_domid, state->ioservid, pci_dev);
+
+ QLIST_FOREACH_SAFE(xendev, &state->dev_list, entry, next) {
+ if (xendev->pci_dev == pci_dev) {
+ QLIST_REMOVE(xendev, entry);
+ g_free(xendev);
+ break;
+ }
+ }
+ }
+}
+
+MemoryListener xen_io_listener = {
+ .region_add = xen_io_add,
+ .region_del = xen_io_del,
+ .priority = 10,
+};
+
+DeviceListener xen_device_listener = {
+ .realize = xen_device_realize,
+ .unrealize = xen_device_unrealize,
+};
+
+/* get the ioreq packets from share mem */
+static ioreq_t *cpu_get_ioreq_from_shared_memory(XenIOState *state, int vcpu)
+{
+ ioreq_t *req = xen_vcpu_ioreq(state->shared_page, vcpu);
+
+ if (req->state != STATE_IOREQ_READY) {
+ DPRINTF("I/O request not ready: "
+ "%x, ptr: %x, port: %"PRIx64", "
+ "data: %"PRIx64", count: %u, size: %u\n",
+ req->state, req->data_is_ptr, req->addr,
+ req->data, req->count, req->size);
+ return NULL;
+ }
+
+ xen_rmb(); /* see IOREQ_READY /then/ read contents of ioreq */
+
+ req->state = STATE_IOREQ_INPROCESS;
+ return req;
+}
+
+/* use poll to get the port notification */
+/* ioreq_vec--out,the */
+/* retval--the number of ioreq packet */
+static ioreq_t *cpu_get_ioreq(XenIOState *state)
+{
+ MachineState *ms = MACHINE(qdev_get_machine());
+ unsigned int max_cpus = ms->smp.max_cpus;
+ int i;
+ evtchn_port_t port;
+
+ port = xenevtchn_pending(state->xce_handle);
+ if (port == state->bufioreq_local_port) {
+ timer_mod(state->buffered_io_timer,
+ BUFFER_IO_MAX_DELAY + qemu_clock_get_ms(QEMU_CLOCK_REALTIME));
+ return NULL;
+ }
+
+ if (port != -1) {
+ for (i = 0; i < max_cpus; i++) {
+ if (state->ioreq_local_port[i] == port) {
+ break;
+ }
+ }
+
+ if (i == max_cpus) {
+ hw_error("Fatal error while trying to get io event!\n");
+ }
+
+ /* unmask the wanted port again */
+ xenevtchn_unmask(state->xce_handle, port);
+
+ /* get the io packet from shared memory */
+ state->send_vcpu = i;
+ return cpu_get_ioreq_from_shared_memory(state, i);
+ }
+
+ /* read error or read nothing */
+ return NULL;
+}
+
+static uint32_t do_inp(uint32_t addr, unsigned long size)
+{
+ switch (size) {
+ case 1:
+ return cpu_inb(addr);
+ case 2:
+ return cpu_inw(addr);
+ case 4:
+ return cpu_inl(addr);
+ default:
+ hw_error("inp: bad size: %04x %lx", addr, size);
+ }
+}
+
+static void do_outp(uint32_t addr,
+ unsigned long size, uint32_t val)
+{
+ switch (size) {
+ case 1:
+ return cpu_outb(addr, val);
+ case 2:
+ return cpu_outw(addr, val);
+ case 4:
+ return cpu_outl(addr, val);
+ default:
+ hw_error("outp: bad size: %04x %lx", addr, size);
+ }
+}
+
+/*
+ * Helper functions which read/write an object from/to physical guest
+ * memory, as part of the implementation of an ioreq.
+ *
+ * Equivalent to
+ * cpu_physical_memory_rw(addr + (req->df ? -1 : +1) * req->size * i,
+ * val, req->size, 0/1)
+ * except without the integer overflow problems.
+ */
+static void rw_phys_req_item(hwaddr addr,
+ ioreq_t *req, uint32_t i, void *val, int rw)
+{
+ /* Do everything unsigned so overflow just results in a truncated result
+ * and accesses to undesired parts of guest memory, which is up
+ * to the guest */
+ hwaddr offset = (hwaddr)req->size * i;
+ if (req->df) {
+ addr -= offset;
+ } else {
+ addr += offset;
+ }
+ cpu_physical_memory_rw(addr, val, req->size, rw);
+}
+
+static inline void read_phys_req_item(hwaddr addr,
+ ioreq_t *req, uint32_t i, void *val)
+{
+ rw_phys_req_item(addr, req, i, val, 0);
+}
+static inline void write_phys_req_item(hwaddr addr,
+ ioreq_t *req, uint32_t i, void *val)
+{
+ rw_phys_req_item(addr, req, i, val, 1);
+}
+
+
+void cpu_ioreq_pio(ioreq_t *req)
+{
+ uint32_t i;
+
+ trace_cpu_ioreq_pio(req, req->dir, req->df, req->data_is_ptr, req->addr,
+ req->data, req->count, req->size);
+
+ if (req->size > sizeof(uint32_t)) {
+ hw_error("PIO: bad size (%u)", req->size);
+ }
+
+ if (req->dir == IOREQ_READ) {
+ if (!req->data_is_ptr) {
+ req->data = do_inp(req->addr, req->size);
+ trace_cpu_ioreq_pio_read_reg(req, req->data, req->addr,
+ req->size);
+ } else {
+ uint32_t tmp;
+
+ for (i = 0; i < req->count; i++) {
+ tmp = do_inp(req->addr, req->size);
+ write_phys_req_item(req->data, req, i, &tmp);
+ }
+ }
+ } else if (req->dir == IOREQ_WRITE) {
+ if (!req->data_is_ptr) {
+ trace_cpu_ioreq_pio_write_reg(req, req->data, req->addr,
+ req->size);
+ do_outp(req->addr, req->size, req->data);
+ } else {
+ for (i = 0; i < req->count; i++) {
+ uint32_t tmp = 0;
+
+ read_phys_req_item(req->data, req, i, &tmp);
+ do_outp(req->addr, req->size, tmp);
+ }
+ }
+ }
+}
+
+static void cpu_ioreq_move(ioreq_t *req)
+{
+ uint32_t i;
+
+ trace_cpu_ioreq_move(req, req->dir, req->df, req->data_is_ptr, req->addr,
+ req->data, req->count, req->size);
+
+ if (req->size > sizeof(req->data)) {
+ hw_error("MMIO: bad size (%u)", req->size);
+ }
+
+ if (!req->data_is_ptr) {
+ if (req->dir == IOREQ_READ) {
+ for (i = 0; i < req->count; i++) {
+ read_phys_req_item(req->addr, req, i, &req->data);
+ }
+ } else if (req->dir == IOREQ_WRITE) {
+ for (i = 0; i < req->count; i++) {
+ write_phys_req_item(req->addr, req, i, &req->data);
+ }
+ }
+ } else {
+ uint64_t tmp;
+
+ if (req->dir == IOREQ_READ) {
+ for (i = 0; i < req->count; i++) {
+ read_phys_req_item(req->addr, req, i, &tmp);
+ write_phys_req_item(req->data, req, i, &tmp);
+ }
+ } else if (req->dir == IOREQ_WRITE) {
+ for (i = 0; i < req->count; i++) {
+ read_phys_req_item(req->data, req, i, &tmp);
+ write_phys_req_item(req->addr, req, i, &tmp);
+ }
+ }
+ }
+}
+
+static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
+{
+ uint32_t sbdf = req->addr >> 32;
+ uint32_t reg = req->addr;
+ XenPciDevice *xendev;
+
+ if (req->size != sizeof(uint8_t) && req->size != sizeof(uint16_t) &&
+ req->size != sizeof(uint32_t)) {
+ hw_error("PCI config access: bad size (%u)", req->size);
+ }
+
+ if (req->count != 1) {
+ hw_error("PCI config access: bad count (%u)", req->count);
+ }
+
+ QLIST_FOREACH(xendev, &state->dev_list, entry) {
+ if (xendev->sbdf != sbdf) {
+ continue;
+ }
+
+ if (!req->data_is_ptr) {
+ if (req->dir == IOREQ_READ) {
+ req->data = pci_host_config_read_common(
+ xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+ req->size);
+ trace_cpu_ioreq_config_read(req, xendev->sbdf, reg,
+ req->size, req->data);
+ } else if (req->dir == IOREQ_WRITE) {
+ trace_cpu_ioreq_config_write(req, xendev->sbdf, reg,
+ req->size, req->data);
+ pci_host_config_write_common(
+ xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+ req->data, req->size);
+ }
+ } else {
+ uint32_t tmp;
+
+ if (req->dir == IOREQ_READ) {
+ tmp = pci_host_config_read_common(
+ xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+ req->size);
+ trace_cpu_ioreq_config_read(req, xendev->sbdf, reg,
+ req->size, tmp);
+ write_phys_req_item(req->data, req, 0, &tmp);
+ } else if (req->dir == IOREQ_WRITE) {
+ read_phys_req_item(req->data, req, 0, &tmp);
+ trace_cpu_ioreq_config_write(req, xendev->sbdf, reg,
+ req->size, tmp);
+ pci_host_config_write_common(
+ xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+ tmp, req->size);
+ }
+ }
+ }
+}
+
+static void handle_ioreq(XenIOState *state, ioreq_t *req)
+{
+ trace_handle_ioreq(req, req->type, req->dir, req->df, req->data_is_ptr,
+ req->addr, req->data, req->count, req->size);
+
+ if (!req->data_is_ptr && (req->dir == IOREQ_WRITE) &&
+ (req->size < sizeof (target_ulong))) {
+ req->data &= ((target_ulong) 1 << (8 * req->size)) - 1;
+ }
+
+ if (req->dir == IOREQ_WRITE)
+ trace_handle_ioreq_write(req, req->type, req->df, req->data_is_ptr,
+ req->addr, req->data, req->count, req->size);
+
+ switch (req->type) {
+ case IOREQ_TYPE_PIO:
+ cpu_ioreq_pio(req);
+ break;
+ case IOREQ_TYPE_COPY:
+ cpu_ioreq_move(req);
+ break;
+ case IOREQ_TYPE_TIMEOFFSET:
+ break;
+ case IOREQ_TYPE_INVALIDATE:
+ xen_invalidate_map_cache();
+ break;
+ case IOREQ_TYPE_PCI_CONFIG:
+ cpu_ioreq_config(state, req);
+ break;
+ default:
+ arch_handle_ioreq(state, req);
+ }
+ if (req->dir == IOREQ_READ) {
+ trace_handle_ioreq_read(req, req->type, req->df, req->data_is_ptr,
+ req->addr, req->data, req->count, req->size);
+ }
+}
+
+static int handle_buffered_iopage(XenIOState *state)
+{
+ buffered_iopage_t *buf_page = state->buffered_io_page;
+ buf_ioreq_t *buf_req = NULL;
+ ioreq_t req;
+ int qw;
+
+ if (!buf_page) {
+ return 0;
+ }
+
+ memset(&req, 0x00, sizeof(req));
+ req.state = STATE_IOREQ_READY;
+ req.count = 1;
+ req.dir = IOREQ_WRITE;
+
+ for (;;) {
+ uint32_t rdptr = buf_page->read_pointer, wrptr;
+
+ xen_rmb();
+ wrptr = buf_page->write_pointer;
+ xen_rmb();
+ if (rdptr != buf_page->read_pointer) {
+ continue;
+ }
+ if (rdptr == wrptr) {
+ break;
+ }
+ buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
+ req.size = 1U << buf_req->size;
+ req.addr = buf_req->addr;
+ req.data = buf_req->data;
+ req.type = buf_req->type;
+ xen_rmb();
+ qw = (req.size == 8);
+ if (qw) {
+ if (rdptr + 1 == wrptr) {
+ hw_error("Incomplete quad word buffered ioreq");
+ }
+ buf_req = &buf_page->buf_ioreq[(rdptr + 1) %
+ IOREQ_BUFFER_SLOT_NUM];
+ req.data |= ((uint64_t)buf_req->data) << 32;
+ xen_rmb();
+ }
+
+ handle_ioreq(state, &req);
+
+ /* Only req.data may get updated by handle_ioreq(), albeit even that
+ * should not happen as such data would never make it to the guest (we
+ * can only usefully see writes here after all).
+ */
+ assert(req.state == STATE_IOREQ_READY);
+ assert(req.count == 1);
+ assert(req.dir == IOREQ_WRITE);
+ assert(!req.data_is_ptr);
+
+ qatomic_add(&buf_page->read_pointer, qw + 1);
+ }
+
+ return req.count;
+}
+
+static void handle_buffered_io(void *opaque)
+{
+ XenIOState *state = opaque;
+
+ if (handle_buffered_iopage(state)) {
+ timer_mod(state->buffered_io_timer,
+ BUFFER_IO_MAX_DELAY + qemu_clock_get_ms(QEMU_CLOCK_REALTIME));
+ } else {
+ timer_del(state->buffered_io_timer);
+ xenevtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+ }
+}
+
+static void cpu_handle_ioreq(void *opaque)
+{
+ XenIOState *state = opaque;
+ ioreq_t *req = cpu_get_ioreq(state);
+
+ handle_buffered_iopage(state);
+ if (req) {
+ ioreq_t copy = *req;
+
+ xen_rmb();
+ handle_ioreq(state, ©);
+ req->data = copy.data;
+
+ if (req->state != STATE_IOREQ_INPROCESS) {
+ fprintf(stderr, "Badness in I/O request ... not in service?!: "
+ "%x, ptr: %x, port: %"PRIx64", "
+ "data: %"PRIx64", count: %u, size: %u, type: %u\n",
+ req->state, req->data_is_ptr, req->addr,
+ req->data, req->count, req->size, req->type);
+ destroy_hvm_domain(false);
+ return;
+ }
+
+ xen_wmb(); /* Update ioreq contents /then/ update state. */
+
+ /*
+ * We do this before we send the response so that the tools
+ * have the opportunity to pick up on the reset before the
+ * guest resumes and does a hlt with interrupts disabled which
+ * causes Xen to powerdown the domain.
+ */
+ if (runstate_is_running()) {
+ ShutdownCause request;
+
+ if (qemu_shutdown_requested_get()) {
+ destroy_hvm_domain(false);
+ }
+ request = qemu_reset_requested_get();
+ if (request) {
+ qemu_system_reset(request);
+ destroy_hvm_domain(true);
+ }
+ }
+
+ req->state = STATE_IORESP_READY;
+ xenevtchn_notify(state->xce_handle,
+ state->ioreq_local_port[state->send_vcpu]);
+ }
+}
+
+static void xen_main_loop_prepare(XenIOState *state)
+{
+ int evtchn_fd = -1;
+
+ if (state->xce_handle != NULL) {
+ evtchn_fd = xenevtchn_fd(state->xce_handle);
+ }
+
+ state->buffered_io_timer = timer_new_ms(QEMU_CLOCK_REALTIME, handle_buffered_io,
+ state);
+
+ if (evtchn_fd != -1) {
+ CPUState *cpu_state;
+
+ DPRINTF("%s: Init cpu_by_vcpu_id\n", __func__);
+ CPU_FOREACH(cpu_state) {
+ DPRINTF("%s: cpu_by_vcpu_id[%d]=%p\n",
+ __func__, cpu_state->cpu_index, cpu_state);
+ state->cpu_by_vcpu_id[cpu_state->cpu_index] = cpu_state;
+ }
+ qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
+ }
+}
+
+
+void xen_hvm_change_state_handler(void *opaque, bool running,
+ RunState rstate)
+{
+ XenIOState *state = opaque;
+
+ if (running) {
+ xen_main_loop_prepare(state);
+ }
+
+ xen_set_ioreq_server_state(xen_domid,
+ state->ioservid,
+ (rstate == RUN_STATE_RUNNING));
+}
+
+void xen_exit_notifier(Notifier *n, void *data)
+{
+ XenIOState *state = container_of(n, XenIOState, exit);
+
+ xen_destroy_ioreq_server(xen_domid, state->ioservid);
+
+ xenevtchn_close(state->xce_handle);
+ xs_daemon_close(state->xenstore);
+}
+
+static int xen_map_ioreq_server(XenIOState *state)
+{
+ void *addr = NULL;
+ xenforeignmemory_resource_handle *fres;
+ xen_pfn_t ioreq_pfn;
+ xen_pfn_t bufioreq_pfn;
+ evtchn_port_t bufioreq_evtchn;
+ int rc;
+
+ /*
+ * Attempt to map using the resource API and fall back to normal
+ * foreign mapping if this is not supported.
+ */
+ QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_bufioreq != 0);
+ QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_ioreq(0) != 1);
+ fres = xenforeignmemory_map_resource(xen_fmem, xen_domid,
+ XENMEM_resource_ioreq_server,
+ state->ioservid, 0, 2,
+ &addr,
+ PROT_READ | PROT_WRITE, 0);
+ if (fres != NULL) {
+ trace_xen_map_resource_ioreq(state->ioservid, addr);
+ state->buffered_io_page = addr;
+ state->shared_page = addr + TARGET_PAGE_SIZE;
+ } else if (errno != EOPNOTSUPP) {
+ error_report("failed to map ioreq server resources: error %d handle=%p",
+ errno, xen_xc);
+ return -1;
+ }
+
+ rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
+ (state->shared_page == NULL) ?
+ &ioreq_pfn : NULL,
+ (state->buffered_io_page == NULL) ?
+ &bufioreq_pfn : NULL,
+ &bufioreq_evtchn);
+ if (rc < 0) {
+ error_report("failed to get ioreq server info: error %d handle=%p",
+ errno, xen_xc);
+ return rc;
+ }
+
+ if (state->shared_page == NULL) {
+ DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+
+ state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
+ PROT_READ | PROT_WRITE,
+ 1, &ioreq_pfn, NULL);
+ if (state->shared_page == NULL) {
+ error_report("map shared IO page returned error %d handle=%p",
+ errno, xen_xc);
+ }
+ }
+
+ if (state->buffered_io_page == NULL) {
+ DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
+
+ state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
+ PROT_READ | PROT_WRITE,
+ 1, &bufioreq_pfn,
+ NULL);
+ if (state->buffered_io_page == NULL) {
+ error_report("map buffered IO page returned error %d", errno);
+ return -1;
+ }
+ }
+
+ if (state->shared_page == NULL || state->buffered_io_page == NULL) {
+ return -1;
+ }
+
+ DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
+
+ state->bufioreq_remote_port = bufioreq_evtchn;
+
+ return 0;
+}
+
+void destroy_hvm_domain(bool reboot)
+{
+ xc_interface *xc_handle;
+ int sts;
+ int rc;
+
+ unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
+
+ if (xen_dmod) {
+ rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
+ if (!rc) {
+ return;
+ }
+ if (errno != ENOTTY /* old Xen */) {
+ perror("xendevicemodel_shutdown failed");
+ }
+ /* well, try the old thing then */
+ }
+
+ xc_handle = xc_interface_open(0, 0, 0);
+ if (xc_handle == NULL) {
+ fprintf(stderr, "Cannot acquire xenctrl handle\n");
+ } else {
+ sts = xc_domain_shutdown(xc_handle, xen_domid, reason);
+ if (sts != 0) {
+ fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
+ "sts %d, %s\n", reboot ? "reboot" : "poweroff",
+ sts, strerror(errno));
+ } else {
+ fprintf(stderr, "Issued domain %d %s\n", xen_domid,
+ reboot ? "reboot" : "poweroff");
+ }
+ xc_interface_close(xc_handle);
+ }
+}
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+ va_list ap;
+
+ va_start(ap, fmt);
+ vfprintf(stderr, fmt, ap);
+ va_end(ap);
+ fprintf(stderr, "Will destroy the domain.\n");
+ /* destroy the domain */
+ qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_ERROR);
+}
+
+void xen_register_ioreq(XenIOState *state, unsigned int max_cpus,
+ MemoryListener xen_memory_listener)
+{
+ int i, rc;
+
+ state->xce_handle = xenevtchn_open(NULL, 0);
+ if (state->xce_handle == NULL) {
+ perror("xen: event channel open");
+ goto err;
+ }
+
+ state->xenstore = xs_daemon_open();
+ if (state->xenstore == NULL) {
+ perror("xen: xenstore open");
+ goto err;
+ }
+
+ xen_create_ioreq_server(xen_domid, &state->ioservid);
+
+ state->exit.notify = xen_exit_notifier;
+ qemu_add_exit_notifier(&state->exit);
+
+ /*
+ * Register wake-up support in QMP query-current-machine API
+ */
+ qemu_register_wakeup_support();
+
+ rc = xen_map_ioreq_server(state);
+ if (rc < 0) {
+ goto err;
+ }
+
+ /* Note: cpus is empty at this point in init */
+ state->cpu_by_vcpu_id = g_malloc0(max_cpus * sizeof(CPUState *));
+
+ rc = xen_set_ioreq_server_state(xen_domid, state->ioservid, true);
+ if (rc < 0) {
+ error_report("failed to enable ioreq server info: error %d handle=%p",
+ errno, xen_xc);
+ goto err;
+ }
+
+ state->ioreq_local_port = g_malloc0(max_cpus * sizeof (evtchn_port_t));
+
+ /* FIXME: how about if we overflow the page here? */
+ for (i = 0; i < max_cpus; i++) {
+ rc = xenevtchn_bind_interdomain(state->xce_handle, xen_domid,
+ xen_vcpu_eport(state->shared_page, i));
+ if (rc == -1) {
+ error_report("shared evtchn %d bind error %d", i, errno);
+ goto err;
+ }
+ state->ioreq_local_port[i] = rc;
+ }
+
+ rc = xenevtchn_bind_interdomain(state->xce_handle, xen_domid,
+ state->bufioreq_remote_port);
+ if (rc == -1) {
+ error_report("buffered evtchn bind error %d", errno);
+ goto err;
+ }
+ state->bufioreq_local_port = rc;
+
+ /* Init RAM management */
+#ifdef XEN_COMPAT_PHYSMAP
+ xen_map_cache_init(xen_phys_offset_to_gaddr, state);
+#else
+ xen_map_cache_init(NULL, state);
+#endif
+
+ qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
+
+ state->memory_listener = xen_memory_listener;
+ memory_listener_register(&state->memory_listener, &address_space_memory);
+
+ state->io_listener = xen_io_listener;
+ memory_listener_register(&state->io_listener, &address_space_io);
+
+ state->device_listener = xen_device_listener;
+ QLIST_INIT(&state->dev_list);
+ device_listener_register(&state->device_listener);
+
+ xen_bus_init();
+
+ /* Initialize backend core & drivers */
+ if (xen_be_init() != 0) {
+ error_report("xen backend core setup failed");
+ goto err;
+ }
+ xen_be_register_common();
+
+ return;
+err:
+ error_report("xen hardware virtual machine initialisation failed");
+ exit(1);
+}
diff --git a/include/hw/i386/xen_arch_hvm.h b/include/hw/i386/xen_arch_hvm.h
index 1b2c71ba4f..1000f8f543 100644
--- a/include/hw/i386/xen_arch_hvm.h
+++ b/include/hw/i386/xen_arch_hvm.h
@@ -2,6 +2,7 @@
#define HW_XEN_ARCH_I386_HVM_H
#include <xen/hvm/ioreq.h>
+#include "hw/xen/xen-hvm-common.h"
void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
void arch_xen_set_memory(XenIOState *state,
diff --git a/include/hw/xen/xen-hvm-common.h b/include/hw/xen/xen-hvm-common.h
new file mode 100644
index 0000000000..c16057835f
--- /dev/null
+++ b/include/hw/xen/xen-hvm-common.h
@@ -0,0 +1,97 @@
+#ifndef HW_XEN_HVM_COMMON_H
+#define HW_XEN_HVM_COMMON_H
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+
+#include "cpu.h"
+#include "hw/pci/pci.h"
+#include "hw/hw.h"
+#include "hw/xen/xen_common.h"
+#include "sysemu/runstate.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/xen.h"
+#include "sysemu/xen-mapcache.h"
+
+#include <xen/hvm/ioreq.h>
+
+extern MemoryRegion ram_memory;
+extern MemoryListener xen_io_listener;
+extern DeviceListener xen_device_listener;
+
+//#define DEBUG_XEN_HVM
+
+#ifdef DEBUG_XEN_HVM
+#define DPRINTF(fmt, ...) \
+ do { fprintf(stderr, "xen: " fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+ do { } while (0)
+#endif
+
+static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i)
+{
+ return shared_page->vcpu_ioreq[i].vp_eport;
+}
+static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
+{
+ return &shared_page->vcpu_ioreq[vcpu];
+}
+
+#define BUFFER_IO_MAX_DELAY 100
+
+typedef struct XenPhysmap {
+ hwaddr start_addr;
+ ram_addr_t size;
+ const char *name;
+ hwaddr phys_offset;
+
+ QLIST_ENTRY(XenPhysmap) list;
+} XenPhysmap;
+
+typedef struct XenPciDevice {
+ PCIDevice *pci_dev;
+ uint32_t sbdf;
+ QLIST_ENTRY(XenPciDevice) entry;
+} XenPciDevice;
+
+typedef struct XenIOState {
+ ioservid_t ioservid;
+ shared_iopage_t *shared_page;
+ buffered_iopage_t *buffered_io_page;
+ QEMUTimer *buffered_io_timer;
+ CPUState **cpu_by_vcpu_id;
+ /* the evtchn port for polling the notification, */
+ evtchn_port_t *ioreq_local_port;
+ /* evtchn remote and local ports for buffered io */
+ evtchn_port_t bufioreq_remote_port;
+ evtchn_port_t bufioreq_local_port;
+ /* the evtchn fd for polling */
+ xenevtchn_handle *xce_handle;
+ /* which vcpu we are serving */
+ int send_vcpu;
+
+ struct xs_handle *xenstore;
+ MemoryListener memory_listener;
+ MemoryListener io_listener;
+ QLIST_HEAD(, XenPciDevice) dev_list;
+ DeviceListener device_listener;
+
+ Notifier exit;
+} XenIOState;
+
+void xen_exit_notifier(Notifier *n, void *data);
+
+void xen_region_add(MemoryListener *listener, MemoryRegionSection *section);
+void xen_region_del(MemoryListener *listener, MemoryRegionSection *section);
+void xen_io_add(MemoryListener *listener, MemoryRegionSection *section);
+void xen_io_del(MemoryListener *listener, MemoryRegionSection *section);
+void xen_device_realize(DeviceListener *listener, DeviceState *dev);
+void xen_device_unrealize(DeviceListener *listener, DeviceState *dev);
+
+void xen_hvm_change_state_handler(void *opaque, bool running, RunState rstate);
+void xen_register_ioreq(XenIOState *state, unsigned int max_cpus,
+ MemoryListener xen_memory_listener);
+
+void cpu_ioreq_pio(ioreq_t *req);
+#endif /* HW_XEN_HVM_COMMON_H */
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 07/12] include/hw/xen/xen_common: return error from xen_create_ioreq_server
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (5 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-16 17:53 ` Julien Grall
2022-10-15 5:07 ` [PATCH v1 08/12] hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration failure Vikram Garhwal
` (6 subsequent siblings)
13 siblings, 1 reply; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, open list:X86 Xen CPUs
From: Stefano Stabellini <stefano.stabellini@amd.com>
This is done to prepare for enabling xenpv support for ARM architecture.
On ARM it is possible to have a functioning xenpv machine with only the
PV backends and no IOREQ server. If the IOREQ server creation fails,
continue to the PV backends initialization.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
include/hw/xen/xen_common.h | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 77ce17d8a4..c2d2f36bde 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -467,8 +467,8 @@ static inline void xen_unmap_pcidev(domid_t dom,
{
}
-static inline void xen_create_ioreq_server(domid_t dom,
- ioservid_t *ioservid)
+static inline int xen_create_ioreq_server(domid_t dom,
+ ioservid_t *ioservid)
{
}
@@ -600,8 +600,8 @@ static inline void xen_unmap_pcidev(domid_t dom,
PCI_FUNC(pci_dev->devfn));
}
-static inline void xen_create_ioreq_server(domid_t dom,
- ioservid_t *ioservid)
+static inline int xen_create_ioreq_server(domid_t dom,
+ ioservid_t *ioservid)
{
int rc = xendevicemodel_create_ioreq_server(xen_dmod, dom,
HVM_IOREQSRV_BUFIOREQ_ATOMIC,
@@ -609,12 +609,14 @@ static inline void xen_create_ioreq_server(domid_t dom,
if (rc == 0) {
trace_xen_ioreq_server_create(*ioservid);
- return;
+ return rc;
}
*ioservid = 0;
use_default_ioreq_server = true;
trace_xen_default_ioreq_server();
+
+ return rc;
}
static inline void xen_destroy_ioreq_server(domid_t dom,
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 08/12] hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration failure
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (6 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 07/12] include/hw/xen/xen_common: return error from xen_create_ioreq_server Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-27 8:46 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state Vikram Garhwal
` (5 subsequent siblings)
13 siblings, 1 reply; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, open list:X86 Xen CPUs
From: Stefano Stabellini <stefano.stabellini@amd.com>
On ARM it is possible to have a functioning xenpv machine with only the
PV backends and no IOREQ server. If the IOREQ server creation fails continue
to the PV backends initialization.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
hw/xen/xen-hvm-common.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index f848f9e625..7bccf595fc 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -777,7 +777,11 @@ void xen_register_ioreq(XenIOState *state, unsigned int max_cpus,
goto err;
}
- xen_create_ioreq_server(xen_domid, &state->ioservid);
+ rc = xen_create_ioreq_server(xen_domid, &state->ioservid);
+ if (rc) {
+ DPRINTF("xen: failed to create ioreq server\n");
+ goto no_ioreq;
+ }
state->exit.notify = xen_exit_notifier;
qemu_add_exit_notifier(&state->exit);
@@ -842,6 +846,7 @@ void xen_register_ioreq(XenIOState *state, unsigned int max_cpus,
QLIST_INIT(&state->dev_list);
device_listener_register(&state->device_listener);
+no_ioreq:
xen_bus_init();
/* Initialize backend core & drivers */
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (7 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 08/12] hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration failure Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-19 16:20 ` Paul Durrant
2022-10-27 9:14 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 10/12] hw/arm: introduce xenpv machine Vikram Garhwal
` (4 subsequent siblings)
13 siblings, 2 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, open list:X86 Xen CPUs
xenstore_record_dm_state() will also be used in aarch64 xenpv machine.
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
accel/xen/xen-all.c | 2 +-
include/hw/xen/xen.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
index 69aa7d018b..276625b78b 100644
--- a/accel/xen/xen-all.c
+++ b/accel/xen/xen-all.c
@@ -100,7 +100,7 @@ void xenstore_store_pv_console_info(int i, Chardev *chr)
}
-static void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
+void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
{
char path[50];
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index afdf9c436a..31e9538a5c 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -9,6 +9,7 @@
*/
#include "exec/cpu-common.h"
+#include <xenstore.h>
/* xen-machine.c */
enum xen_mode {
@@ -31,5 +32,6 @@ qemu_irq *xen_interrupt_controller_init(void);
void xenstore_store_pv_console_info(int i, Chardev *chr);
void xen_register_framebuffer(struct MemoryRegion *mr);
+void xenstore_record_dm_state(struct xs_handle *xs, const char *state);
#endif /* QEMU_HW_XEN_H */
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (8 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-16 17:47 ` Julien Grall
` (2 more replies)
2022-10-15 5:07 ` [PATCH v1 11/12] meson.build: enable xenpv machine build for ARM Vikram Garhwal
` (3 subsequent siblings)
13 siblings, 3 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel
Cc: vikram.garhwal, stefano.stabellini, Peter Maydell,
Stefano Stabellini, Anthony Perard, Paul Durrant,
open list:ARM TCG CPUs, open list:X86 Xen CPUs
Add a new machine xenpv which creates a IOREQ server to register/connect with
Xen Hypervisor.
Xen IOREQ connection expect the TARGET_PAGE_SIZE to 4096, and the xenpv machine
on ARM will have no CPU definitions. We need to define TARGET_PAGE_SIZE
appropriately ourselves.
Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
TPM emulator and connects to swtpm running on host machine via chardev socket
and support TPM functionalities for a guest domain.
Extra command line for aarch64 xenpv QEMU to connect to swtpm:
-chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
-tpmdev emulator,id=tpm0,chardev=chrtpm \
swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
provides access to TPM functionality over socket, chardev and CUSE interface.
Github repo: https://github.com/stefanberger/swtpm
Example for starting swtpm on host machine:
mkdir /tmp/vtpm2
swtpm socket --tpmstate dir=/tmp/vtpm2 \
--ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
hw/arm/meson.build | 2 +
hw/arm/xen_arm.c | 163 ++++++++++++++++++++++++++++++++++
include/hw/arm/xen_arch_hvm.h | 12 +++
include/hw/xen/arch_hvm.h | 2 +
4 files changed, 179 insertions(+)
create mode 100644 hw/arm/xen_arm.c
create mode 100644 include/hw/arm/xen_arch_hvm.h
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 92f9f6e000..0cae024374 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -62,5 +62,7 @@ arm_ss.add(when: 'CONFIG_FSL_IMX7', if_true: files('fsl-imx7.c', 'mcimx7d-sabre.
arm_ss.add(when: 'CONFIG_ARM_SMMUV3', if_true: files('smmu-common.c', 'smmuv3.c'))
arm_ss.add(when: 'CONFIG_FSL_IMX6UL', if_true: files('fsl-imx6ul.c', 'mcimx6ul-evk.c'))
arm_ss.add(when: 'CONFIG_NRF51_SOC', if_true: files('nrf51_soc.c'))
+arm_ss.add(when: 'CONFIG_XEN', if_true: files('xen_arm.c'))
+arm_ss.add_all(xen_ss)
hw_arch += {'arm': arm_ss}
diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
new file mode 100644
index 0000000000..0b900314cc
--- /dev/null
+++ b/hw/arm/xen_arm.c
@@ -0,0 +1,163 @@
+/*
+ * QEMU ARM Xen PV Machine
+ *
+ *
+ * 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.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/error-report.h"
+#include "qapi/qapi-commands-migration.h"
+#include "hw/boards.h"
+#include "hw/sysbus.h"
+#include "sysemu/block-backend.h"
+#include "sysemu/tpm_backend.h"
+#include "sysemu/sysemu.h"
+#include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-hvm-common.h"
+#include "sysemu/tpm.h"
+#include "hw/xen/arch_hvm.h"
+
+#define TYPE_XEN_ARM MACHINE_TYPE_NAME("xenpv")
+OBJECT_DECLARE_SIMPLE_TYPE(XenArmState, XEN_ARM)
+
+static MemoryListener xen_memory_listener = {
+ .region_add = xen_region_add,
+ .region_del = xen_region_del,
+ .log_start = NULL,
+ .log_stop = NULL,
+ .log_sync = NULL,
+ .log_global_start = NULL,
+ .log_global_stop = NULL,
+ .priority = 10,
+};
+
+struct XenArmState {
+ /*< private >*/
+ MachineState parent;
+
+ XenIOState *state;
+};
+
+void arch_handle_ioreq(XenIOState *state, ioreq_t *req)
+{
+ hw_error("Invalid ioreq type 0x%x\n", req->type);
+
+ return;
+}
+
+void arch_xen_set_memory(XenIOState *state, MemoryRegionSection *section,
+ bool add)
+{
+}
+
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
+
+static int xen_init_ioreq(XenIOState *state, unsigned int max_cpus)
+{
+ xen_dmod = xendevicemodel_open(0, 0);
+ xen_xc = xc_interface_open(0, 0, 0);
+
+ if (xen_xc == NULL) {
+ perror("xen: can't open xen interface\n");
+ return -1;
+ }
+
+ xen_fmem = xenforeignmemory_open(0, 0);
+ if (xen_fmem == NULL) {
+ perror("xen: can't open xen fmem interface\n");
+ xc_interface_close(xen_xc);
+ return -1;
+ }
+
+ xen_register_ioreq(state, max_cpus, xen_memory_listener);
+
+ xenstore_record_dm_state(xenstore, "running");
+
+ return 0;
+}
+
+static void xen_enable_tpm(void)
+{
+/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
+#ifdef CONFIG_TPM
+ Error *errp = NULL;
+ DeviceState *dev;
+ SysBusDevice *busdev;
+
+ TPMBackend *be = qemu_find_tpm_be("tpm0");
+ if (be == NULL) {
+ DPRINTF("Couldn't fine the backend for tpm0\n");
+ return;
+ }
+ dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
+ object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
+ object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
+ busdev = SYS_BUS_DEVICE(dev);
+ sysbus_realize_and_unref(busdev, &error_fatal);
+ sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
+
+ DPRINTF("Connected tpmdev at address 0x%lx\n", GUEST_TPM_BASE);
+#endif
+}
+
+static void xen_arm_init(MachineState *machine)
+{
+ XenArmState *xam = XEN_ARM(machine);
+
+ xam->state = g_new0(XenIOState, 1);
+
+ if (xen_init_ioreq(xam->state, machine->smp.cpus)) {
+ return;
+ }
+
+ xen_enable_tpm();
+
+ return;
+}
+
+static void xen_arm_machine_class_init(ObjectClass *oc, void *data)
+{
+
+ MachineClass *mc = MACHINE_CLASS(oc);
+ mc->desc = "Xen Para-virtualized PC";
+ mc->init = xen_arm_init;
+ mc->max_cpus = 1;
+ machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
+}
+
+static const TypeInfo xen_arm_machine_type = {
+ .name = TYPE_XEN_ARM,
+ .parent = TYPE_MACHINE,
+ .class_init = xen_arm_machine_class_init,
+ .instance_size = sizeof(XenArmState),
+};
+
+static void xen_arm_machine_register_types(void)
+{
+ type_register_static(&xen_arm_machine_type);
+}
+
+type_init(xen_arm_machine_register_types)
diff --git a/include/hw/arm/xen_arch_hvm.h b/include/hw/arm/xen_arch_hvm.h
new file mode 100644
index 0000000000..f645dfec28
--- /dev/null
+++ b/include/hw/arm/xen_arch_hvm.h
@@ -0,0 +1,12 @@
+#ifndef HW_XEN_ARCH_ARM_HVM_H
+#define HW_XEN_ARCH_ARM_HVM_H
+
+#include <xen/hvm/ioreq.h>
+void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
+void arch_xen_set_memory(XenIOState *state,
+ MemoryRegionSection *section,
+ bool add);
+
+#undef TARGET_PAGE_SIZE
+#define TARGET_PAGE_SIZE 4096
+#endif
diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
index 26674648d8..c7c515220d 100644
--- a/include/hw/xen/arch_hvm.h
+++ b/include/hw/xen/arch_hvm.h
@@ -1,3 +1,5 @@
#if defined(TARGET_I386) || defined(TARGET_X86_64)
#include "hw/i386/xen_arch_hvm.h"
+#elif defined(TARGET_ARM) || defined(TARGET_ARM_64)
+#include "hw/arm/xen_arch_hvm.h"
#endif
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 11/12] meson.build: enable xenpv machine build for ARM
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (9 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 10/12] hw/arm: introduce xenpv machine Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-27 9:11 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 12/12] meson.build: do not set have_xen_pci_passthrough for aarch64 targets Vikram Garhwal
` (2 subsequent siblings)
13 siblings, 1 reply; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel; +Cc: vikram.garhwal, stefano.stabellini
Add CONFIG_XEN for aarch64 device to support build for ARM targets.
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index b686dfef75..0027d7d195 100644
--- a/meson.build
+++ b/meson.build
@@ -125,7 +125,7 @@ endif
if cpu in ['x86', 'x86_64', 'arm', 'aarch64']
# i386 emulator provides xenpv machine type for multiple architectures
accelerator_targets += {
- 'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu'],
+ 'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu', 'aarch64-softmmu'],
}
endif
if cpu in ['x86', 'x86_64']
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v1 12/12] meson.build: do not set have_xen_pci_passthrough for aarch64 targets
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (10 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 11/12] meson.build: enable xenpv machine build for ARM Vikram Garhwal
@ 2022-10-15 5:07 ` Vikram Garhwal
2022-10-27 9:14 ` Alex Bennée
2022-10-27 8:26 ` [PATCH v1 00/12] Introduce xenpv machine for arm architecture Alex Bennée
2022-10-27 9:24 ` Alex Bennée
13 siblings, 1 reply; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-15 5:07 UTC (permalink / raw)
To: qemu-devel; +Cc: vikram.garhwal, stefano.stabellini
From: Stefano Stabellini <stefano.stabellini@amd.com>
have_xen_pci_passthrough is only used for Xen x86 VMs.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
meson.build | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meson.build b/meson.build
index 0027d7d195..43e70936ee 100644
--- a/meson.build
+++ b/meson.build
@@ -1454,6 +1454,8 @@ have_xen_pci_passthrough = get_option('xen_pci_passthrough') \
error_message: 'Xen PCI passthrough requested but Xen not enabled') \
.require(targetos == 'linux',
error_message: 'Xen PCI passthrough not available on this platform') \
+ .require(cpu == 'x86' or cpu == 'x86_64',
+ error_message: 'Xen PCI passthrough not available on this platform') \
.allowed()
--
2.17.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-15 5:07 ` [PATCH v1 10/12] hw/arm: introduce xenpv machine Vikram Garhwal
@ 2022-10-16 17:47 ` Julien Grall
2022-10-18 1:26 ` Stefano Stabellini
` (2 more replies)
2022-10-27 8:02 ` Alex Bennée
2022-10-27 8:40 ` Alex Bennée
2 siblings, 3 replies; 50+ messages in thread
From: Julien Grall @ 2022-10-16 17:47 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Peter Maydell, Stefano Stabellini,
Anthony Perard, Paul Durrant, open list:ARM TCG CPUs,
open list:X86 Xen CPUs
Hi,
There seem to be some missing patches on xen-devel (including the cover
letter). Is that expected?
On 15/10/2022 06:07, Vikram Garhwal wrote:
> Add a new machine xenpv which creates a IOREQ server to register/connect with
> Xen Hypervisor.
I don't like the name 'xenpv' because it doesn't convey the fact that
some of the HW may be emulated rather than para-virtualized. In fact one
may only want to use for emulating devices.
Potential name would be 'xen-arm' or re-using 'virt' but with
'accel=xen' to select a Xen layout.
>
> Xen IOREQ connection expect the TARGET_PAGE_SIZE to 4096, and the xenpv machine
> on ARM will have no CPU definitions. We need to define TARGET_PAGE_SIZE
> appropriately ourselves.
>
> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
> TPM emulator and connects to swtpm running on host machine via chardev socket
> and support TPM functionalities for a guest domain.
>
> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
> -tpmdev emulator,id=tpm0,chardev=chrtpm \
>
> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
> provides access to TPM functionality over socket, chardev and CUSE interface.
> Github repo: https://github.com/stefanberger/swtpm
> Example for starting swtpm on host machine:
> mkdir /tmp/vtpm2
> swtpm socket --tpmstate dir=/tmp/vtpm2 \
> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
I see patches for QEMU but not Xen. How can this be tested with existing
Xen? Will libxl ever create QEMU?
[...]
> +static int xen_init_ioreq(XenIOState *state, unsigned int max_cpus)
> +{
> + xen_dmod = xendevicemodel_open(0, 0);
> + xen_xc = xc_interface_open(0, 0, 0);
> +
> + if (xen_xc == NULL) {
You are checking xen_xc but not xen_dmod. Why?
> + perror("xen: can't open xen interface\n");
> + return -1;
> + }
> +
> + xen_fmem = xenforeignmemory_open(0, 0);
> + if (xen_fmem == NULL) {
> + perror("xen: can't open xen fmem interface\n");
> + xc_interface_close(xen_xc);
> + return -1;
> + }
> +
> + xen_register_ioreq(state, max_cpus, xen_memory_listener);
> +
> + xenstore_record_dm_state(xenstore, "running");
> +
> + return 0;
> +}
> +
> +static void xen_enable_tpm(void)
> +{
> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
> +#ifdef CONFIG_TPM
> + Error *errp = NULL;
> + DeviceState *dev;
> + SysBusDevice *busdev;
> +
> + TPMBackend *be = qemu_find_tpm_be("tpm0");
> + if (be == NULL) {
> + DPRINTF("Couldn't fine the backend for tpm0\n");
> + return;
> + }
> + dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
> + object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
> + object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
> + busdev = SYS_BUS_DEVICE(dev);
> + sysbus_realize_and_unref(busdev, &error_fatal);
> + sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
I can't find where GUEST_TPM_BASE is defined. But then the guest memory
layout is not expected to be stable. With your current approach, it
means QEMU would need to be rebuilt for every Xen version. Is it what we
want?
> +
> + DPRINTF("Connected tpmdev at address 0x%lx\n", GUEST_TPM_BASE);
> +#endif
> +}
> +
> +static void xen_arm_init(MachineState *machine)
> +{
> + XenArmState *xam = XEN_ARM(machine);
> +
> + xam->state = g_new0(XenIOState, 1);
> +
> + if (xen_init_ioreq(xam->state, machine->smp.cpus)) {
> + return;
In another patch, you said the IOREQ would be optional. IHMO, I think
this is a bad idea to register it by default because one may only want
to use PV drivers. Registering IOREQ will add unnecessary overhead in Xen.
Furthermore, it means that someone selecting TPM but Xen is not built
with CONFIG_IOREQ=y (BTW This is still a tech preview but there are
security holes on Arm...) will not get an error. Instead, the OS will
until it crashes when trying to access the TPM.
Overall I think it would be better if IOREQ is only registered when a
device requires (like TPM) it *and* throw an error if there is a problem
during the initialization.
> + } > +
> + xen_enable_tpm();
> +
> + return;
> +}
> +
> +static void xen_arm_machine_class_init(ObjectClass *oc, void *data)
> +{
> +
> + MachineClass *mc = MACHINE_CLASS(oc);
> + mc->desc = "Xen Para-virtualized PC";
> + mc->init = xen_arm_init;
> + mc->max_cpus = 1;
> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
Shouldn't this be protected with #ifdef CONFIG_TPM?
> +}
> +
> +static const TypeInfo xen_arm_machine_type = {
> + .name = TYPE_XEN_ARM,
> + .parent = TYPE_MACHINE,
> + .class_init = xen_arm_machine_class_init,
> + .instance_size = sizeof(XenArmState),
> +};
> +
> +static void xen_arm_machine_register_types(void)
> +{
> + type_register_static(&xen_arm_machine_type);
> +}
> +
> +type_init(xen_arm_machine_register_types)
> diff --git a/include/hw/arm/xen_arch_hvm.h b/include/hw/arm/xen_arch_hvm.h
> new file mode 100644
> index 0000000000..f645dfec28
> --- /dev/null
> +++ b/include/hw/arm/xen_arch_hvm.h
> @@ -0,0 +1,12 @@
> +#ifndef HW_XEN_ARCH_ARM_HVM_H
> +#define HW_XEN_ARCH_ARM_HVM_H
> +
> +#include <xen/hvm/ioreq.h>
> +void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> +void arch_xen_set_memory(XenIOState *state,
> + MemoryRegionSection *section,
> + bool add);
> +
> +#undef TARGET_PAGE_SIZE
I am a bit puzzled with this #undef. In the commit message you said that
there will be no CPU definition. So the implications is this should not
be defined.
If it is defined, then what guarantees that all the source will use the
correct value?
> +#define TARGET_PAGE_SIZE 4096
It would be better to use XC_PAGE_SIZE (or similar) rather than
hardcoding it.
> +#endif
> diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
> index 26674648d8..c7c515220d 100644
> --- a/include/hw/xen/arch_hvm.h
> +++ b/include/hw/xen/arch_hvm.h
> @@ -1,3 +1,5 @@
> #if defined(TARGET_I386) || defined(TARGET_X86_64)
> #include "hw/i386/xen_arch_hvm.h"
> +#elif defined(TARGET_ARM) || defined(TARGET_ARM_64)
> +#include "hw/arm/xen_arch_hvm.h"
> #endif
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 07/12] include/hw/xen/xen_common: return error from xen_create_ioreq_server
2022-10-15 5:07 ` [PATCH v1 07/12] include/hw/xen/xen_common: return error from xen_create_ioreq_server Vikram Garhwal
@ 2022-10-16 17:53 ` Julien Grall
0 siblings, 0 replies; 50+ messages in thread
From: Julien Grall @ 2022-10-16 17:53 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
Paul Durrant, open list:X86 Xen CPUs
Hi Vikram,
On 15/10/2022 06:07, Vikram Garhwal wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> This is done to prepare for enabling xenpv support for ARM architecture.
> On ARM it is possible to have a functioning xenpv machine with only the
> PV backends and no IOREQ server. If the IOREQ server creation fails,
> continue to the PV backends initialization.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> include/hw/xen/xen_common.h | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 77ce17d8a4..c2d2f36bde 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -467,8 +467,8 @@ static inline void xen_unmap_pcidev(domid_t dom,
> {
> }
>
> -static inline void xen_create_ioreq_server(domid_t dom,
> - ioservid_t *ioservid)
> +static inline int xen_create_ioreq_server(domid_t dom,
> + ioservid_t *ioservid)
> {
I think there is a return missing here.
> }
>
> @@ -600,8 +600,8 @@ static inline void xen_unmap_pcidev(domid_t dom,
> PCI_FUNC(pci_dev->devfn));
> }
>
> -static inline void xen_create_ioreq_server(domid_t dom,
> - ioservid_t *ioservid)
> +static inline int xen_create_ioreq_server(domid_t dom,
> + ioservid_t *ioservid)
> {
> int rc = xendevicemodel_create_ioreq_server(xen_dmod, dom,
> HVM_IOREQSRV_BUFIOREQ_ATOMIC,
> @@ -609,12 +609,14 @@ static inline void xen_create_ioreq_server(domid_t dom,
>
> if (rc == 0) {
> trace_xen_ioreq_server_create(*ioservid);
> - return;
> + return rc;
> }
>
> *ioservid = 0;
> use_default_ioreq_server = true;
> trace_xen_default_ioreq_server();
> +
> + return rc;
> }
>
> static inline void xen_destroy_ioreq_server(domid_t dom,
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c
2022-10-15 5:07 ` [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c Vikram Garhwal
@ 2022-10-16 18:07 ` Julien Grall
2022-10-19 16:16 ` Paul Durrant
1 sibling, 0 replies; 50+ messages in thread
From: Julien Grall @ 2022-10-16 18:07 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
Paul Durrant, Michael S. Tsirkin, Marcel Apfelbaum,
Paolo Bonzini, Richard Henderson, Eduardo Habkost,
open list:X86 Xen CPUs
Hi Vikram,
On 15/10/2022 06:07, Vikram Garhwal wrote:
> +void xen_register_ioreq(XenIOState *state, unsigned int max_cpus,
> + MemoryListener xen_memory_listener)
> +{
[...]
> +
> + xen_bus_init();
> +
> + /* Initialize backend core & drivers */
> + if (xen_be_init() != 0) {
> + error_report("xen backend core setup failed");
> + goto err;
> + }
> + xen_be_register_common();
Calling xen_be_init() and xen_be_register_common() from
xen_register_ioreq() sounds wrong to me. There are no dependency between
the two. I think it would be better to create a new function to register
backends.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-16 17:47 ` Julien Grall
@ 2022-10-18 1:26 ` Stefano Stabellini
2022-10-18 8:24 ` Julien Grall
2022-10-27 8:37 ` Alex Bennée
2022-12-02 3:24 ` Garhwal, Vikram
2 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2022-10-18 1:26 UTC (permalink / raw)
To: Julien Grall
Cc: Vikram Garhwal, qemu-devel, stefano.stabellini, Peter Maydell,
Stefano Stabellini, Anthony Perard, Paul Durrant,
open list:ARM TCG CPUs, open list:X86 Xen CPUs
On Sun, 16 Oct 2022, Julien Grall wrote:
> Hi,
>
> There seem to be some missing patches on xen-devel (including the cover
> letter). Is that expected?
>
> On 15/10/2022 06:07, Vikram Garhwal wrote:
> > Add a new machine xenpv which creates a IOREQ server to register/connect
> > with
> > Xen Hypervisor.
>
> I don't like the name 'xenpv' because it doesn't convey the fact that some of
> the HW may be emulated rather than para-virtualized. In fact one may only want
> to use for emulating devices.
>
> Potential name would be 'xen-arm' or re-using 'virt' but with 'accel=xen' to
> select a Xen layout.
The benefit of 'xenpv' is that it doesn't require any changes to libxl.
It is even backward compatible so it could be used with an older version
of Xen/libxl. Backward compatibility aside, if we come up with a
different name then we'll need changes to libxl and to manage those
changes. For instance, if we use 'xen-arm' that would mean we would need
to handle per-arch QEMU machine names.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-18 1:26 ` Stefano Stabellini
@ 2022-10-18 8:24 ` Julien Grall
2022-10-19 0:15 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2022-10-18 8:24 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Vikram Garhwal, qemu-devel, stefano.stabellini, Peter Maydell,
Anthony Perard, Paul Durrant, open list:ARM TCG CPUs,
open list:X86 Xen CPUs
Hi Stefano,
On 18/10/2022 02:26, Stefano Stabellini wrote:
> On Sun, 16 Oct 2022, Julien Grall wrote:
>> Hi,
>>
>> There seem to be some missing patches on xen-devel (including the cover
>> letter). Is that expected?
>>
>> On 15/10/2022 06:07, Vikram Garhwal wrote:
>>> Add a new machine xenpv which creates a IOREQ server to register/connect
>>> with
>>> Xen Hypervisor.
>>
>> I don't like the name 'xenpv' because it doesn't convey the fact that some of
>> the HW may be emulated rather than para-virtualized. In fact one may only want
>> to use for emulating devices.
>>
>> Potential name would be 'xen-arm' or re-using 'virt' but with 'accel=xen' to
>> select a Xen layout.
>
> The benefit of 'xenpv' is that it doesn't require any changes to libxl.
I am quite surprised. Looking at the code, it seems to work more by
chance than it is intentional as the code is gated by
libxl__need_xenpv_qemu(). So it would not start if there were no
emulated devices.
> It is even backward compatible so it could be used with an older version
> of Xen/libxl.
We don't really gain much here. IOREQ is a tech preview and anyone that
wants to try it should really use the latest Xen.
> Backward compatibility aside, if we come up with a
> different name then we'll need changes to libxl and to manage those
> changes. For instance, if we use 'xen-arm' that would mean we would need
> to handle per-arch QEMU machine names.
Right, so the main argument here is for simplicity in libxl
Looking at how 'xenpv' is built, this is really expected to deal with PV
backend rather than emulated device. I do expect some changes as we go
along to be able to add emulated device.
Furthermore, libxl is not the only toolstack out. So I am not convinced
this is a good argument to keep the name the same.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-18 8:24 ` Julien Grall
@ 2022-10-19 0:15 ` Stefano Stabellini
2022-10-19 9:49 ` Julien Grall
0 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2022-10-19 0:15 UTC (permalink / raw)
To: Julien Grall
Cc: Stefano Stabellini, Vikram Garhwal, qemu-devel,
stefano.stabellini, Peter Maydell, Anthony Perard, Paul Durrant,
open list:ARM TCG CPUs, open list:X86 Xen CPUs
On Tue, 18 Oct 2022, Julien Grall wrote:
> On 18/10/2022 02:26, Stefano Stabellini wrote:
> > On Sun, 16 Oct 2022, Julien Grall wrote:
> > > Hi,
> > >
> > > There seem to be some missing patches on xen-devel (including the cover
> > > letter). Is that expected?
> > >
> > > On 15/10/2022 06:07, Vikram Garhwal wrote:
> > > > Add a new machine xenpv which creates a IOREQ server to register/connect
> > > > with
> > > > Xen Hypervisor.
> > >
> > > I don't like the name 'xenpv' because it doesn't convey the fact that some
> > > of
> > > the HW may be emulated rather than para-virtualized. In fact one may only
> > > want
> > > to use for emulating devices.
> > >
> > > Potential name would be 'xen-arm' or re-using 'virt' but with 'accel=xen'
> > > to
> > > select a Xen layout.
> >
> > The benefit of 'xenpv' is that it doesn't require any changes to libxl.
>
> I am quite surprised. Looking at the code, it seems to work more by chance
> than it is intentional as the code is gated by libxl__need_xenpv_qemu(). So it
> would not start if there were no emulated devices.
>
> > It is even backward compatible so it could be used with an older version
> > of Xen/libxl.
> We don't really gain much here. IOREQ is a tech preview and anyone that wants
> to try it should really use the latest Xen.
I think that's fair.
> > Backward compatibility aside, if we come up with a
> > different name then we'll need changes to libxl and to manage those
> > changes. For instance, if we use 'xen-arm' that would mean we would need
> > to handle per-arch QEMU machine names.
>
> Right, so the main argument here is for simplicity in libxl
Yeah
> Looking at how 'xenpv' is built, this is really expected to deal with PV
> backend rather than emulated device. I do expect some changes as we go along
> to be able to add emulated device.
>
> Furthermore, libxl is not the only toolstack out. So I am not convinced this
> is a good argument to keep the name the same.
Let's think some more about the naming strategy. From a QEMU point of
view we could choose any name we like (Vikram please confirm), the issue
is really on the libxl side.
Today libxl understands two QEMU "machines": xenpv and xenfv
(pc,accel=xen is the same as xenfv, I'll use xenfv in this email for
simplicity).
xenpv is for PV guests and only provides PV backends, no emulation. It
is used on both ARM and x86.
xenfv is only used on x86, and it is for HVM guests, with a full set of
emulated hardware (PIIX3, etc.).
The purpose of this series is to introduce a QEMU machine that:
- works on ARM (but could maybe work on other archs as a stretch goal)
- provides PV backends
- no emulated devices by default
- also can emulate selected devices on request
Certainly it is not xenfv or pc,accel=xen because they would with more
emulation by default. This is more like "xenpvh": an extension to PV
with also the capability of emulating one device as requested. It is not
intended to emulate a full PC and doesn't do that by default like xenfv.
If/When x86 PVH gains the ability to use QEMU as IOREQ server, I would
imagine it would run a QEMU machine similar to this one.
This is also how I would imagine it would get integrated in libxl: as a
xenpv + individual emulated devices. Not as HVM for ARM. The other QEMU
command line arguments are inline with the xenpv command line arguments
rather than xenfv command line arguments. This is why the libxl changes
are small to zero to make it work today.
So, I think the following options work:
a) call it "xenpv" because it is an extension of the old xenpv machine
b) call it "xenpvh" because it is PV + few individual emulated devices
If we call it xenpv there are fewer changes in libxl. If we call it
xenpvh there are more changes in libxl but we can distinguish xenpv from
xenpvh (I don't see why we need it right now, but I could imagine it
could turn out useful in the future.)
I would stay away from arch-specific machine names because it will make
it harder on the libxl side without immediate benefits.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-19 0:15 ` Stefano Stabellini
@ 2022-10-19 9:49 ` Julien Grall
0 siblings, 0 replies; 50+ messages in thread
From: Julien Grall @ 2022-10-19 9:49 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Vikram Garhwal, qemu-devel, stefano.stabellini, Peter Maydell,
Anthony Perard, Paul Durrant, open list:ARM TCG CPUs,
open list:X86 Xen CPUs
Hi Stefano,
On 19/10/2022 01:15, Stefano Stabellini wrote:
> On Tue, 18 Oct 2022, Julien Grall wrote:
>> On 18/10/2022 02:26, Stefano Stabellini wrote:
>>> On Sun, 16 Oct 2022, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> There seem to be some missing patches on xen-devel (including the cover
>>>> letter). Is that expected?
>>>>
>>>> On 15/10/2022 06:07, Vikram Garhwal wrote:
>>>>> Add a new machine xenpv which creates a IOREQ server to register/connect
>>>>> with
>>>>> Xen Hypervisor.
>>>>
>>>> I don't like the name 'xenpv' because it doesn't convey the fact that some
>>>> of
>>>> the HW may be emulated rather than para-virtualized. In fact one may only
>>>> want
>>>> to use for emulating devices.
>>>>
>>>> Potential name would be 'xen-arm' or re-using 'virt' but with 'accel=xen'
>>>> to
>>>> select a Xen layout.
>>>
>>> The benefit of 'xenpv' is that it doesn't require any changes to libxl.
>>
>> I am quite surprised. Looking at the code, it seems to work more by chance
>> than it is intentional as the code is gated by libxl__need_xenpv_qemu(). So it
>> would not start if there were no emulated devices.
>>
>>> It is even backward compatible so it could be used with an older version
>>> of Xen/libxl.
>> We don't really gain much here. IOREQ is a tech preview and anyone that wants
>> to try it should really use the latest Xen.
>
> I think that's fair.
>
>
>>> Backward compatibility aside, if we come up with a
>>> different name then we'll need changes to libxl and to manage those
>>> changes. For instance, if we use 'xen-arm' that would mean we would need
>>> to handle per-arch QEMU machine names.
>>
>> Right, so the main argument here is for simplicity in libxl
>
> Yeah
>
>
>> Looking at how 'xenpv' is built, this is really expected to deal with PV
>> backend rather than emulated device. I do expect some changes as we go along
>> to be able to add emulated device.
>>
>> Furthermore, libxl is not the only toolstack out. So I am not convinced this
>> is a good argument to keep the name the same.
>
> Let's think some more about the naming strategy. From a QEMU point of
> view we could choose any name we like (Vikram please confirm), the issue
> is really on the libxl side.
>
> Today libxl understands two QEMU "machines": xenpv and xenfv
> (pc,accel=xen is the same as xenfv, I'll use xenfv in this email for
> simplicity).
>
> xenpv is for PV guests and only provides PV backends, no emulation. It
> is used on both ARM and x86.
>
> xenfv is only used on x86, and it is for HVM guests, with a full set of
> emulated hardware (PIIX3, etc.).
>
> The purpose of this series is to introduce a QEMU machine that:
> - works on ARM (but could maybe work on other archs as a stretch goal)
> - provides PV backends
> - no emulated devices by default
> - also can emulate selected devices on request
>
> Certainly it is not xenfv or pc,accel=xen because they would with more
> emulation by default. This is more like "xenpvh": an extension to PV
> with also the capability of emulating one device as requested. It is not
> intended to emulate a full PC and doesn't do that by default like xenfv.
The definition of "full PC" is not very clear for me. Unlike x86, Arm
doesn't have legacy devices that needs to be emulated. So technically,
if we emulated one network card and one block device, then we would be
able potentially be able to boot an unaware OS on Xen on Arm. This would
be the same as if you passthrough-ed the two devices.
In the past, I have seen interest to boot OS like Windows OS/iOS on Arm.
I do expect that the addition of a Xen platform in QEMU will lead to
another increase of the interest because we could expose anything to the
VM. Although, it might need some tweak in Xen to allow more dynamic
layout just in case an OS doesn't discover dynamically devices.
>
> If/When x86 PVH gains the ability to use QEMU as IOREQ server, I would
> imagine it would run a QEMU machine similar to this one.
To me it would sounds odd to add emulated devices in the 'xenpv' because
they would only work for PVH domain. AFAIK, QEMU doesn't know whether a
domain is PV or PVH. So we would solely rely on IOREQ to return an error.
>
> This is also how I would imagine it would get integrated in libxl: as a
> xenpv + individual emulated devices. Not as HVM for ARM. The other QEMU
> command line arguments are inline with the xenpv command line arguments
> rather than xenfv command line arguments. This is why the libxl changes
> are small to zero to make it work today.
>
> So, I think the following options work:
>
> a) call it "xenpv" because it is an extension of the old xenpv machine
> b) call it "xenpvh" because it is PV + few individual emulated devices
>
> If we call it xenpv there are fewer changes in libxl. If we call it
> xenpvh there are more changes in libxl but we can distinguish xenpv from
> xenpvh (I don't see why we need it right now, but I could imagine it
> could turn out useful in the future.)
IMHO, we need to plan for the future.
>
> I would stay away from arch-specific machine names because it will make
> it harder on the libxl side without immediate benefits.
If the name is the only change, then I would expect this could be done
with a per-arch define. So that would be a few lines change maximum.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub
2022-10-15 5:07 ` [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub Vikram Garhwal
@ 2022-10-19 14:46 ` Paul Durrant
2022-10-26 19:01 ` Alex Bennée
1 sibling, 0 replies; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 14:46 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
> Build fails when have_xen_pci_passthrough is disabled. This is because of
> incorrect build configuration for xen_pt_stub.c.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/
2022-10-15 5:07 ` [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/ Vikram Garhwal
@ 2022-10-19 14:53 ` Paul Durrant
2022-12-01 20:25 ` Garhwal, Vikram
0 siblings, 1 reply; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 14:53 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Michael S. Tsirkin, Marcel Apfelbaum,
Paolo Bonzini, Richard Henderson, Eduardo Habkost,
Stefano Stabellini, Anthony Perard, open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
> xen-mapcache.c contains common functions which can be used for enabling Xen on
> aarch64 with IOREQ handling. Moving it out from hw/i386/xen to hw/xen to make it
> accessible for both aarch64 and x86.
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> hw/i386/meson.build | 1 +
> hw/i386/xen/meson.build | 1 -
> hw/i386/xen/trace-events | 5 -----
> hw/xen/meson.build | 4 ++++
> hw/xen/trace-events | 5 +++++
> hw/{i386 => }/xen/xen-mapcache.c | 0
> 6 files changed, 10 insertions(+), 6 deletions(-)
> rename hw/{i386 => }/xen/xen-mapcache.c (100%)
>
> diff --git a/hw/i386/meson.build b/hw/i386/meson.build
> index 213e2e82b3..cfdbfdcbcb 100644
> --- a/hw/i386/meson.build
> +++ b/hw/i386/meson.build
> @@ -33,5 +33,6 @@ subdir('kvm')
> subdir('xen')
>
> i386_ss.add_all(xenpv_ss)
> +i386_ss.add_all(xen_ss)
>
> hw_arch += {'i386': i386_ss}
> diff --git a/hw/i386/xen/meson.build b/hw/i386/xen/meson.build
> index be84130300..2fcc46e6ca 100644
> --- a/hw/i386/xen/meson.build
> +++ b/hw/i386/xen/meson.build
> @@ -1,6 +1,5 @@
> i386_ss.add(when: 'CONFIG_XEN', if_true: files(
> 'xen-hvm.c',
> - 'xen-mapcache.c',
> 'xen_apic.c',
> 'xen_platform.c',
> 'xen_pvdevice.c',
> diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
> index 5d6be61090..a0c89d91c4 100644
> --- a/hw/i386/xen/trace-events
> +++ b/hw/i386/xen/trace-events
> @@ -21,8 +21,3 @@ xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
> cpu_ioreq_config_read(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
> cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
>
> -# xen-mapcache.c
> -xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
> -xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
> -xen_map_cache_return(void* ptr) "%p"
> -
> diff --git a/hw/xen/meson.build b/hw/xen/meson.build
> index ae0ace3046..19d0637c46 100644
> --- a/hw/xen/meson.build
> +++ b/hw/xen/meson.build
> @@ -22,3 +22,7 @@ else
> endif
>
> specific_ss.add_all(when: ['CONFIG_XEN', xen], if_true: xen_specific_ss)
> +
> +xen_ss = ss.source_set()
> +
> +xen_ss.add(when: 'CONFIG_XEN', if_true: files('xen-mapcache.c'))
Curious as to why you couldn't just add this to the softmmu_ss list above?
Paul
> diff --git a/hw/xen/trace-events b/hw/xen/trace-events
> index 3da3fd8348..2c8f238f42 100644
> --- a/hw/xen/trace-events
> +++ b/hw/xen/trace-events
> @@ -41,3 +41,8 @@ xs_node_vprintf(char *path, char *value) "%s %s"
> xs_node_vscanf(char *path, char *value) "%s %s"
> xs_node_watch(char *path) "%s"
> xs_node_unwatch(char *path) "%s"
> +
> +# xen-mapcache.c
> +xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
> +xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
> +xen_map_cache_return(void* ptr) "%p"
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
> similarity index 100%
> rename from hw/i386/xen/xen-mapcache.c
> rename to hw/xen/xen-mapcache.c
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 03/12] hw/i386/xen: rearrange xen_hvm_init_pc
2022-10-15 5:07 ` [PATCH v1 03/12] hw/i386/xen: rearrange xen_hvm_init_pc Vikram Garhwal
@ 2022-10-19 14:59 ` Paul Durrant
0 siblings, 0 replies; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 14:59 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
Paolo Bonzini, Richard Henderson, Eduardo Habkost,
Michael S. Tsirkin, Marcel Apfelbaum, open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
> In preparation to moving most of xen-hvm code to an arch-neutral location,
> move non IOREQ references to:
> - xen_get_vmport_regs_pfn
> - xen_suspend_notifier
> - xen_wakeup_notifier
> - xen_ram_init
>
> towards the end of the xen_hvm_init_pc() function.
>
> This is done to keep the common ioreq functions in one place which will be
> moved to new function in next patch in order to make it common to both x86 and
> aarch64 machines.
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState
2022-10-15 5:07 ` [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState Vikram Garhwal
@ 2022-10-19 15:56 ` Paul Durrant
2022-10-19 16:00 ` Paul Durrant
2022-10-27 8:59 ` Alex Bennée
2 siblings, 0 replies; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 15:56 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
Michael S. Tsirkin, Marcel Apfelbaum, Paolo Bonzini,
Richard Henderson, Eduardo Habkost, open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> In preparation to moving most of xen-hvm code to an arch-neutral location, move:
> - shared_vmport_page
> - log_for_dirtybit
> - dirty_bitmap
> - suspend
> - wakeup
>
> out of XenIOState struct as these are only used on x86, especially the ones
> related to dirty logging.
> Updated XenIOState can be used for both aarch64 and x86.
>
> Also, remove free_phys_offset as it was unused.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState
2022-10-15 5:07 ` [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState Vikram Garhwal
2022-10-19 15:56 ` Paul Durrant
@ 2022-10-19 16:00 ` Paul Durrant
2022-10-27 8:59 ` Alex Bennée
2 siblings, 0 replies; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 16:00 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
Michael S. Tsirkin, Marcel Apfelbaum, Paolo Bonzini,
Richard Henderson, Eduardo Habkost, open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> In preparation to moving most of xen-hvm code to an arch-neutral location, move:
> - shared_vmport_page
> - log_for_dirtybit
> - dirty_bitmap
> - suspend
> - wakeup
>
> out of XenIOState struct as these are only used on x86, especially the ones
> related to dirty logging.
> Updated XenIOState can be used for both aarch64 and x86.
>
> Also, remove free_phys_offset as it was unused.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory
2022-10-15 5:07 ` [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory Vikram Garhwal
@ 2022-10-19 16:09 ` Paul Durrant
2022-10-27 9:02 ` Alex Bennée
1 sibling, 0 replies; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 16:09 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
Michael S. Tsirkin, Marcel Apfelbaum, Paolo Bonzini,
Richard Henderson, Eduardo Habkost, open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> In preparation to moving most of xen-hvm code to an arch-neutral location,
> move the x86-specific portion of xen_set_memory to arch_xen_set_memory.
>
> Also move handle_vmport_ioreq to arch_handle_ioreq.
>
> NOTE: This patch breaks the build. Next patch fixes the build issue.
> Reason behind creating this patch is because there is lot of new code addition
> and pure code movement done for enabling Xen on ARM. Keeping the this patch
> separate is done to make it easier to review.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c
2022-10-15 5:07 ` [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c Vikram Garhwal
2022-10-16 18:07 ` Julien Grall
@ 2022-10-19 16:16 ` Paul Durrant
2022-10-19 23:12 ` Garhwal, Vikram
1 sibling, 1 reply; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 16:16 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
Michael S. Tsirkin, Marcel Apfelbaum, Paolo Bonzini,
Richard Henderson, Eduardo Habkost, open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
[snip]
> + qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
> +
> + state->memory_listener = xen_memory_listener;
> + memory_listener_register(&state->memory_listener, &address_space_memory);
> +
> + state->io_listener = xen_io_listener;
> + memory_listener_register(&state->io_listener, &address_space_io);
> +
> + state->device_listener = xen_device_listener;
> + QLIST_INIT(&state->dev_list);
> + device_listener_register(&state->device_listener);
> +
As Julien said, these do not belong here. These are the (current and
legacy) PV backend setup functions; they most certainly have nothing to
do with device emulation.
Paul
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
2022-10-15 5:07 ` [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state Vikram Garhwal
@ 2022-10-19 16:20 ` Paul Durrant
2022-10-27 9:14 ` Alex Bennée
1 sibling, 0 replies; 50+ messages in thread
From: Paul Durrant @ 2022-10-19 16:20 UTC (permalink / raw)
To: Vikram Garhwal, qemu-devel
Cc: stefano.stabellini, Stefano Stabellini, Anthony Perard,
open list:X86 Xen CPUs
On 15/10/2022 06:07, Vikram Garhwal wrote:
> xenstore_record_dm_state() will also be used in aarch64 xenpv machine.
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c
2022-10-19 16:16 ` Paul Durrant
@ 2022-10-19 23:12 ` Garhwal, Vikram
0 siblings, 0 replies; 50+ messages in thread
From: Garhwal, Vikram @ 2022-10-19 23:12 UTC (permalink / raw)
To: Paul Durrant, qemu-devel
Cc: Stabellini, Stefano, Stefano Stabellini, Anthony Perard,
Michael S. Tsirkin, Marcel Apfelbaum, Paolo Bonzini,
Richard Henderson, Eduardo Habkost, open list:X86 Xen CPUs
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
Thanks Paul & Julien for reviewing. I will update this in v2.
Regards,
Vikram
From: Paul Durrant <xadimgnik@gmail.com>
Date: Wednesday, October 19, 2022 at 9:16 AM
To: Garhwal, Vikram <vikram.garhwal@amd.com>, qemu-devel@nongnu.org <qemu-devel@nongnu.org>
Cc: Stabellini, Stefano <stefano.stabellini@amd.com>, Stefano Stabellini <sstabellini@kernel.org>, Anthony Perard <anthony.perard@citrix.com>, Michael S. Tsirkin <mst@redhat.com>, Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <richard.henderson@linaro.org>, Eduardo Habkost <eduardo@habkost.net>, open list:X86 Xen CPUs <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c
On 15/10/2022 06:07, Vikram Garhwal wrote:
[snip]
> + qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
> +
> + state->memory_listener = xen_memory_listener;
> + memory_listener_register(&state->memory_listener, &address_space_memory);
> +
> + state->io_listener = xen_io_listener;
> + memory_listener_register(&state->io_listener, &address_space_io);
> +
> + state->device_listener = xen_device_listener;
> + QLIST_INIT(&state->dev_list);
> + device_listener_register(&state->device_listener);
> +
As Julien said, these do not belong here. These are the (current and
legacy) PV backend setup functions; they most certainly have nothing to
do with device emulation.
Paul
[-- Attachment #2: Type: text/html, Size: 3930 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub
2022-10-15 5:07 ` [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub Vikram Garhwal
2022-10-19 14:46 ` Paul Durrant
@ 2022-10-26 19:01 ` Alex Bennée
1 sibling, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-26 19:01 UTC (permalink / raw)
To: Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, xen-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> Build fails when have_xen_pci_passthrough is disabled. This is because of
> incorrect build configuration for xen_pt_stub.c.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-15 5:07 ` [PATCH v1 10/12] hw/arm: introduce xenpv machine Vikram Garhwal
2022-10-16 17:47 ` Julien Grall
@ 2022-10-27 8:02 ` Alex Bennée
2022-10-28 17:57 ` Julien Grall
2022-10-27 8:40 ` Alex Bennée
2 siblings, 1 reply; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 8:02 UTC (permalink / raw)
To: Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Peter Maydell,
Stefano Stabellini, Anthony Perard, Paul Durrant,
open list:ARM TCG CPUs, xen-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
<snip>
> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
> TPM emulator and connects to swtpm running on host machine via chardev socket
> and support TPM functionalities for a guest domain.
>
> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
> -tpmdev emulator,id=tpm0,chardev=chrtpm \
>
> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
> provides access to TPM functionality over socket, chardev and CUSE interface.
> Github repo: https://github.com/stefanberger/swtpm
> Example for starting swtpm on host machine:
> mkdir /tmp/vtpm2
> swtpm socket --tpmstate dir=/tmp/vtpm2 \
> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
<snip>
> +static void xen_enable_tpm(void)
> +{
> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
> +#ifdef CONFIG_TPM
> + Error *errp = NULL;
> + DeviceState *dev;
> + SysBusDevice *busdev;
> +
> + TPMBackend *be = qemu_find_tpm_be("tpm0");
> + if (be == NULL) {
> + DPRINTF("Couldn't fine the backend for tpm0\n");
> + return;
> + }
> + dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
> + object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
> + object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
> + busdev = SYS_BUS_DEVICE(dev);
> + sysbus_realize_and_unref(busdev, &error_fatal);
> + sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
I'm not sure what has gone wrong here but I'm getting:
../../hw/arm/xen_arm.c: In function ‘xen_enable_tpm’:
../../hw/arm/xen_arm.c:120:32: error: ‘GUEST_TPM_BASE’ undeclared (first use in this function); did you mean ‘GUEST_RAM_BASE’?
120 | sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
| ^~~~~~~~~~~~~~
| GUEST_RAM_BASE
../../hw/arm/xen_arm.c:120:32: note: each undeclared identifier is reported only once for each function it appears in
In my cross build:
# Configured with: '../../configure' '--disable-docs' '--target-list=aarch64-softmmu' '--disable-kvm' '--enable-xen' '--disable-opengl' '--disable-libudev' '--enable-tpm' '--disable-xen-pci-passthrough' '--cross-prefix=aarch64-linux-gnu-' '--skip-meson'
which makes me wonder if this is a configure failure or a confusion
about being able to have host swtpm implementations during emulation but
needing target tpm for Xen?
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 00/12] Introduce xenpv machine for arm architecture
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (11 preceding siblings ...)
2022-10-15 5:07 ` [PATCH v1 12/12] meson.build: do not set have_xen_pci_passthrough for aarch64 targets Vikram Garhwal
@ 2022-10-27 8:26 ` Alex Bennée
2022-10-27 9:24 ` Alex Bennée
13 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 8:26 UTC (permalink / raw)
To: Vikram Garhwal; +Cc: stefano.stabellini, qemu-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> Hi,
> This series add xenpv machine for aarch64. Motivation behind creating xenpv
> machine with IOREQ and TPM was to enable each guest on Xen aarch64 to have it's
> own unique and emulated TPM.
>
> This series does following:
> 1. Moved common xen functionalities from hw/i386/xen to hw/xen/ so those can
> be used for aarch64.
> 2. We added a minimal xenpv arm machine which creates an IOREQ server and
> support TPM.
Now I have some CI minutes again:
https://gitlab.com/stsquad/qemu/-/pipelines/677956972/failures
which broadly break down into:
* GUEST_TPM_BASE define missing
* #include <xenstore.h> failure on builds that don't enable Xen
* CPUTLBEntryFull f; breakage (tcg bits in a non-tcg build?)
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-16 17:47 ` Julien Grall
2022-10-18 1:26 ` Stefano Stabellini
@ 2022-10-27 8:37 ` Alex Bennée
2022-12-02 3:24 ` Garhwal, Vikram
2 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 8:37 UTC (permalink / raw)
To: Julien Grall
Cc: Vikram Garhwal, stefano.stabellini, Peter Maydell,
Stefano Stabellini, Anthony Perard, Paul Durrant,
open list:ARM TCG CPUs, open list:X86 Xen CPUs, qemu-devel
Julien Grall <julien@xen.org> writes:
> Hi,
>
> There seem to be some missing patches on xen-devel (including the
> cover letter). Is that expected?
>
> On 15/10/2022 06:07, Vikram Garhwal wrote:
>> Add a new machine xenpv which creates a IOREQ server to register/connect with
>> Xen Hypervisor.
>
> I don't like the name 'xenpv' because it doesn't convey the fact that
> some of the HW may be emulated rather than para-virtualized. In fact
> one may only want to use for emulating devices.
>
> Potential name would be 'xen-arm' or re-using 'virt' but with
> 'accel=xen' to select a Xen layout.
I don't think you can re-use the machine name and select by accelerator
because the virt machine does quite a lot of other stuff this model
doesn't support. However I've been calling this concept "xen-virt" or
maybe the explicit "xen-virtio" because that is what it is targeting.
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-15 5:07 ` [PATCH v1 10/12] hw/arm: introduce xenpv machine Vikram Garhwal
2022-10-16 17:47 ` Julien Grall
2022-10-27 8:02 ` Alex Bennée
@ 2022-10-27 8:40 ` Alex Bennée
2 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 8:40 UTC (permalink / raw)
To: Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Peter Maydell,
Stefano Stabellini, Anthony Perard, Paul Durrant,
open list:ARM TCG CPUs, xen-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> Add a new machine xenpv which creates a IOREQ server to register/connect with
> Xen Hypervisor.
>
<snip>
> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
> TPM emulator and connects to swtpm running on host machine via chardev socket
> and support TPM functionalities for a guest domain.
<snip>
> +
> +static void xen_arm_machine_class_init(ObjectClass *oc, void *data)
> +{
> +
> + MachineClass *mc = MACHINE_CLASS(oc);
> + mc->desc = "Xen Para-virtualized PC";
> + mc->init = xen_arm_init;
> + mc->max_cpus = 1;
> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
This needs #ifdef CONFIG_TPM because while doing --disable-tpm to try
and get the cross build working it then fails with:
../../hw/arm/xen_arm.c: In function ‘xen_arm_machine_class_init’:
../../hw/arm/xen_arm.c:148:48: error: ‘TYPE_TPM_TIS_SYSBUS’ undeclared (first use in this function)
148 | machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
| ^~~~~~~~~~~~~~~~~~~
../../hw/arm/xen_arm.c:148:48: note: each undeclared identifier is reported only once for each function it appears in
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 08/12] hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration failure
2022-10-15 5:07 ` [PATCH v1 08/12] hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration failure Vikram Garhwal
@ 2022-10-27 8:46 ` Alex Bennée
0 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 8:46 UTC (permalink / raw)
To: Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, xen-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> On ARM it is possible to have a functioning xenpv machine with only the
> PV backends and no IOREQ server. If the IOREQ server creation fails continue
> to the PV backends initialization.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> hw/xen/xen-hvm-common.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
> index f848f9e625..7bccf595fc 100644
> --- a/hw/xen/xen-hvm-common.c
> +++ b/hw/xen/xen-hvm-common.c
> @@ -777,7 +777,11 @@ void xen_register_ioreq(XenIOState *state, unsigned int max_cpus,
> goto err;
> }
>
> - xen_create_ioreq_server(xen_domid, &state->ioservid);
> + rc = xen_create_ioreq_server(xen_domid, &state->ioservid);
> + if (rc) {
> + DPRINTF("xen: failed to create ioreq server\n");
This should be a warn_report to properly inform the user.
> + goto no_ioreq;
Maybe pushing the rest of this function into a local subroutine would
reduce the amount of goto messing about. Other candidates for cleaning
up/modernising:
- g_malloc to g_new0
- perror -> error_setg_errno
> + }
>
> state->exit.notify = xen_exit_notifier;
> qemu_add_exit_notifier(&state->exit);
> @@ -842,6 +846,7 @@ void xen_register_ioreq(XenIOState *state, unsigned int max_cpus,
> QLIST_INIT(&state->dev_list);
> device_listener_register(&state->device_listener);
>
> +no_ioreq:
> xen_bus_init();
>
> /* Initialize backend core & drivers */
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState
2022-10-15 5:07 ` [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState Vikram Garhwal
2022-10-19 15:56 ` Paul Durrant
2022-10-19 16:00 ` Paul Durrant
@ 2022-10-27 8:59 ` Alex Bennée
2 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 8:59 UTC (permalink / raw)
To: Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, Michael S. Tsirkin,
Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
Eduardo Habkost, xen-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> In preparation to moving most of xen-hvm code to an arch-neutral location, move:
> - shared_vmport_page
> - log_for_dirtybit
> - dirty_bitmap
> - suspend
> - wakeup
>
> out of XenIOState struct as these are only used on x86, especially the ones
> related to dirty logging.
> Updated XenIOState can be used for both aarch64 and x86.
>
> Also, remove free_phys_offset as it was unused.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory
2022-10-15 5:07 ` [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory Vikram Garhwal
2022-10-19 16:09 ` Paul Durrant
@ 2022-10-27 9:02 ` Alex Bennée
1 sibling, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 9:02 UTC (permalink / raw)
To: Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, Michael S. Tsirkin,
Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
Eduardo Habkost, xen-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> In preparation to moving most of xen-hvm code to an arch-neutral location,
> move the x86-specific portion of xen_set_memory to arch_xen_set_memory.
>
> Also move handle_vmport_ioreq to arch_handle_ioreq.
>
> NOTE: This patch breaks the build. Next patch fixes the build issue.
> Reason behind creating this patch is because there is lot of new code addition
> and pure code movement done for enabling Xen on ARM. Keeping the this patch
> separate is done to make it easier to review.
But you do intend to squash the patches for the final version? We don't
want to intentionally break bisection.
Otherwise:
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 11/12] meson.build: enable xenpv machine build for ARM
2022-10-15 5:07 ` [PATCH v1 11/12] meson.build: enable xenpv machine build for ARM Vikram Garhwal
@ 2022-10-27 9:11 ` Alex Bennée
0 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 9:11 UTC (permalink / raw)
To: Vikram Garhwal; +Cc: stefano.stabellini, qemu-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> Add CONFIG_XEN for aarch64 device to support build for ARM targets.
So to be clear a --enable-xen only build for any of these binaries
essentially ends up being the same thing just with a slightly less
discombobulating name?
Maybe given there is no real architecture specific stuff we should just
create a neutral binary for --enable-xen (e.g. qemu-xen-backend)?
Anyway:
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index b686dfef75..0027d7d195 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -125,7 +125,7 @@ endif
> if cpu in ['x86', 'x86_64', 'arm', 'aarch64']
> # i386 emulator provides xenpv machine type for multiple architectures
> accelerator_targets += {
> - 'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu'],
> + 'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu', 'aarch64-softmmu'],
> }
> endif
> if cpu in ['x86', 'x86_64']
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 12/12] meson.build: do not set have_xen_pci_passthrough for aarch64 targets
2022-10-15 5:07 ` [PATCH v1 12/12] meson.build: do not set have_xen_pci_passthrough for aarch64 targets Vikram Garhwal
@ 2022-10-27 9:14 ` Alex Bennée
0 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 9:14 UTC (permalink / raw)
To: Vikram Garhwal; +Cc: stefano.stabellini, qemu-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> From: Stefano Stabellini <stefano.stabellini@amd.com>
>
> have_xen_pci_passthrough is only used for Xen x86 VMs.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
I think this might want to before 11/12. Anyway:
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> meson.build | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meson.build b/meson.build
> index 0027d7d195..43e70936ee 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1454,6 +1454,8 @@ have_xen_pci_passthrough = get_option('xen_pci_passthrough') \
> error_message: 'Xen PCI passthrough requested but Xen not enabled') \
> .require(targetos == 'linux',
> error_message: 'Xen PCI passthrough not available on this platform') \
> + .require(cpu == 'x86' or cpu == 'x86_64',
> + error_message: 'Xen PCI passthrough not available on this platform') \
> .allowed()
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
2022-10-15 5:07 ` [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state Vikram Garhwal
2022-10-19 16:20 ` Paul Durrant
@ 2022-10-27 9:14 ` Alex Bennée
2022-10-28 20:26 ` Oleksandr Tyshchenko
2022-10-29 5:22 ` Garhwal, Vikram
1 sibling, 2 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 9:14 UTC (permalink / raw)
To: Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Stefano Stabellini,
Anthony Perard, Paul Durrant, xen-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> xenstore_record_dm_state() will also be used in aarch64 xenpv machine.
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> accel/xen/xen-all.c | 2 +-
> include/hw/xen/xen.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
> index 69aa7d018b..276625b78b 100644
> --- a/accel/xen/xen-all.c
> +++ b/accel/xen/xen-all.c
> @@ -100,7 +100,7 @@ void xenstore_store_pv_console_info(int i, Chardev *chr)
> }
>
>
> -static void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
> +void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
> {
> char path[50];
>
> diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> index afdf9c436a..31e9538a5c 100644
> --- a/include/hw/xen/xen.h
> +++ b/include/hw/xen/xen.h
> @@ -9,6 +9,7 @@
> */
>
> #include "exec/cpu-common.h"
> +#include <xenstore.h>
This is breaking a bunch of the builds and generally we try and avoid
adding system includes in headers (apart from osdep.h) for this reason.
In fact there is a comment just above to that fact.
I think you can just add struct xs_handle to typedefs.h (or maybe just
xen.h) and directly include xenstore.h in xen-all.c following the usual
rules:
https://qemu.readthedocs.io/en/latest/devel/style.html#include-directives
It might be worth doing an audit to see what else is including xen.h
needlessly or should be using sysemu/xen.h.
>
> /* xen-machine.c */
> enum xen_mode {
> @@ -31,5 +32,6 @@ qemu_irq *xen_interrupt_controller_init(void);
> void xenstore_store_pv_console_info(int i, Chardev *chr);
>
> void xen_register_framebuffer(struct MemoryRegion *mr);
> +void xenstore_record_dm_state(struct xs_handle *xs, const char *state);
>
> #endif /* QEMU_HW_XEN_H */
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 00/12] Introduce xenpv machine for arm architecture
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
` (12 preceding siblings ...)
2022-10-27 8:26 ` [PATCH v1 00/12] Introduce xenpv machine for arm architecture Alex Bennée
@ 2022-10-27 9:24 ` Alex Bennée
13 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-10-27 9:24 UTC (permalink / raw)
To: Vikram Garhwal; +Cc: stefano.stabellini, qemu-devel
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> Hi,
> This series add xenpv machine for aarch64. Motivation behind creating xenpv
> machine with IOREQ and TPM was to enable each guest on Xen aarch64 to have it's
> own unique and emulated TPM.
>
> This series does following:
> 1. Moved common xen functionalities from hw/i386/xen to hw/xen/ so those can
> be used for aarch64.
> 2. We added a minimal xenpv arm machine which creates an IOREQ server and
> support TPM.
>
> Please note that patch 05/12 breaks the build. Patch 06/12 fixes the build
> issue. If needed we can merge patch 05/12 and 06/12. For now we kept these
> separate to make changes easy to review.
>
> Also, checkpatch.pl fails for 03/12 and 06/12. These fails are due to
> moving old code to new place which was not QEMU code style compatible.
> No new add code was added.
I've finished my review pass. Please CC me on v2 when it's ready ;-)
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-27 8:02 ` Alex Bennée
@ 2022-10-28 17:57 ` Julien Grall
2022-10-28 19:05 ` Oleksandr Tyshchenko
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2022-10-28 17:57 UTC (permalink / raw)
To: Alex Bennée, Vikram Garhwal
Cc: qemu-devel, stefano.stabellini, Peter Maydell,
Stefano Stabellini, Anthony Perard, Paul Durrant,
open list:ARM TCG CPUs, xen-devel
Hi,
On 27/10/2022 09:02, Alex Bennée wrote:
>
> Vikram Garhwal <vikram.garhwal@amd.com> writes:
>
> <snip>
>> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
>> TPM emulator and connects to swtpm running on host machine via chardev socket
>> and support TPM functionalities for a guest domain.
>>
>> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
>> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
>> -tpmdev emulator,id=tpm0,chardev=chrtpm \
>>
>> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
>> provides access to TPM functionality over socket, chardev and CUSE interface.
>> Github repo: https://github.com/stefanberger/swtpm
>> Example for starting swtpm on host machine:
>> mkdir /tmp/vtpm2
>> swtpm socket --tpmstate dir=/tmp/vtpm2 \
>> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
>
> <snip>
>> +static void xen_enable_tpm(void)
>> +{
>> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
>> +#ifdef CONFIG_TPM
>> + Error *errp = NULL;
>> + DeviceState *dev;
>> + SysBusDevice *busdev;
>> +
>> + TPMBackend *be = qemu_find_tpm_be("tpm0");
>> + if (be == NULL) {
>> + DPRINTF("Couldn't fine the backend for tpm0\n");
>> + return;
>> + }
>> + dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
>> + object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
>> + object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
>> + busdev = SYS_BUS_DEVICE(dev);
>> + sysbus_realize_and_unref(busdev, &error_fatal);
>> + sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
>
> I'm not sure what has gone wrong here but I'm getting:
>
> ../../hw/arm/xen_arm.c: In function ‘xen_enable_tpm’:
> ../../hw/arm/xen_arm.c:120:32: error: ‘GUEST_TPM_BASE’ undeclared (first use in this function); did you mean ‘GUEST_RAM_BASE’?
> 120 | sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
> | ^~~~~~~~~~~~~~
> | GUEST_RAM_BASE
> ../../hw/arm/xen_arm.c:120:32: note: each undeclared identifier is reported only once for each function it appears in
>
> In my cross build:
>
> # Configured with: '../../configure' '--disable-docs' '--target-list=aarch64-softmmu' '--disable-kvm' '--enable-xen' '--disable-opengl' '--disable-libudev' '--enable-tpm' '--disable-xen-pci-passthrough' '--cross-prefix=aarch64-linux-gnu-' '--skip-meson'
>
> which makes me wonder if this is a configure failure or a confusion
> about being able to have host swtpm implementations during emulation but
> needing target tpm for Xen?
I was also wondering where is that value come from. Note that the
memory/IRQ layout exposed to the guest is not stable.
Are we expecting the user to rebuild QEMU for every Xen versions (or
possibly every guest if we ever allow dynamic layout in Xen)?
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-28 17:57 ` Julien Grall
@ 2022-10-28 19:05 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 50+ messages in thread
From: Oleksandr Tyshchenko @ 2022-10-28 19:05 UTC (permalink / raw)
To: Julien Grall, Vikram Garhwal, stefano.stabellini
Cc: qemu-devel, Peter Maydell, Stefano Stabellini, Anthony Perard,
Paul Durrant, open list:ARM TCG CPUs, xen-devel,
Alex Bennée
[-- Attachment #1: Type: text/plain, Size: 4603 bytes --]
On Fri, Oct 28, 2022 at 8:58 PM Julien Grall <julien@xen.org> wrote:
> Hi,
>
Hello all.
[sorry for the possible format issues]
>
> On 27/10/2022 09:02, Alex Bennée wrote:
> >
> > Vikram Garhwal <vikram.garhwal@amd.com> writes:
> >
> > <snip>
> >> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device,
> adds a
> >> TPM emulator and connects to swtpm running on host machine via chardev
> socket
> >> and support TPM functionalities for a guest domain.
> >>
> >> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
> >> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
> >> -tpmdev emulator,id=tpm0,chardev=chrtpm \
> >>
> >> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on
> libtpms and
> >> provides access to TPM functionality over socket, chardev and CUSE
> interface.
> >> Github repo: https://github.com/stefanberger/swtpm
> >> Example for starting swtpm on host machine:
> >> mkdir /tmp/vtpm2
> >> swtpm socket --tpmstate dir=/tmp/vtpm2 \
> >> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
> >
> > <snip>
> >> +static void xen_enable_tpm(void)
> >> +{
> >> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
> >> +#ifdef CONFIG_TPM
> >> + Error *errp = NULL;
> >> + DeviceState *dev;
> >> + SysBusDevice *busdev;
> >> +
> >> + TPMBackend *be = qemu_find_tpm_be("tpm0");
> >> + if (be == NULL) {
> >> + DPRINTF("Couldn't fine the backend for tpm0\n");
> >> + return;
> >> + }
> >> + dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
> >> + object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
> >> + object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
> >> + busdev = SYS_BUS_DEVICE(dev);
> >> + sysbus_realize_and_unref(busdev, &error_fatal);
> >> + sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
> >
> > I'm not sure what has gone wrong here but I'm getting:
> >
> > ../../hw/arm/xen_arm.c: In function ‘xen_enable_tpm’:
> > ../../hw/arm/xen_arm.c:120:32: error: ‘GUEST_TPM_BASE’ undeclared
> (first use in this function); did you mean ‘GUEST_RAM_BASE’?
> > 120 | sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
> > | ^~~~~~~~~~~~~~
> > | GUEST_RAM_BASE
> > ../../hw/arm/xen_arm.c:120:32: note: each undeclared identifier is
> reported only once for each function it appears in
> >
> > In my cross build:
> >
> > # Configured with: '../../configure' '--disable-docs'
> '--target-list=aarch64-softmmu' '--disable-kvm' '--enable-xen'
> '--disable-opengl' '--disable-libudev' '--enable-tpm'
> '--disable-xen-pci-passthrough' '--cross-prefix=aarch64-linux-gnu-'
> '--skip-meson'
> >
> > which makes me wonder if this is a configure failure or a confusion
> > about being able to have host swtpm implementations during emulation but
> > needing target tpm for Xen?
>
> I was also wondering where is that value come from. Note that the
> memory/IRQ layout exposed to the guest is not stable.
>
> Are we expecting the user to rebuild QEMU for every Xen versions (or
> possibly every guest if we ever allow dynamic layout in Xen)?
>
This doesn't sound ideal.
I am wondering what would be the correct way here assuming that we would
likely need to have more such information in place for supporting more
use-cases...
For instance, the PCI host bridge emulation in Qemu. Xen toolstack (another
software layer) generates device-tree for the guest, so creates PCI Host
bridge node by using reserved regions from Guest OS interface (arch-arm.h):
- GUEST_VPCI_MEM_ADDR (GUEST_VPCI_MEM_SIZE)
- GUEST_VPCI_ECAM_BASE (GUEST_VPCI_ECAM_SIZE)
- GUEST_VPCI_PREFETCH_MEM_ADDR (GUEST_VPCI_PREFETCH_MEM_SIZE)
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libs/light/libxl_arm.c;h=2a5e93c28403738779863aded31d2df3ba72f8c0;hb=HEAD#l833
Here in Qemu when creating a PCI Host bridge we would need to use exactly
the same reserved regions which toolstack writes in the corresponding
device-tree node. So how to tell Qemu about them?
1. Introduce new cmd line arguments?
2. Using Xenstore?
3. Anything else?
I am afraid this would be related to every device that we want to emulate
in Qemu and for which the toolstack needs to generate device-tree node by
using something defined with GUEST_*, unless I really missed something.
>
> Cheers,
>
> --
> Julien Grall
>
>
--
Regards,
Oleksandr Tyshchenko
[-- Attachment #2: Type: text/html, Size: 6869 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
2022-10-27 9:14 ` Alex Bennée
@ 2022-10-28 20:26 ` Oleksandr Tyshchenko
2022-10-29 5:36 ` Vikram Garhwal
2022-10-29 5:22 ` Garhwal, Vikram
1 sibling, 1 reply; 50+ messages in thread
From: Oleksandr Tyshchenko @ 2022-10-28 20:26 UTC (permalink / raw)
To: Vikram Garhwal, stefano.stabellini
Cc: qemu-devel, Stefano Stabellini, Anthony Perard, Paul Durrant,
Alex Bennée, xen-devel
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
On Thu, Oct 27, 2022 at 12:24 PM Alex Bennée <alex.bennee@linaro.org> wrote:
Hello all
> Vikram Garhwal <vikram.garhwal@amd.com> writes:
>
> > xenstore_record_dm_state() will also be used in aarch64 xenpv machine.
> >
> > Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> > ---
> > accel/xen/xen-all.c | 2 +-
> > include/hw/xen/xen.h | 2 ++
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
> > index 69aa7d018b..276625b78b 100644
> > --- a/accel/xen/xen-all.c
> > +++ b/accel/xen/xen-all.c
> > @@ -100,7 +100,7 @@ void xenstore_store_pv_console_info(int i, Chardev
> *chr)
> > }
> >
> >
> > -static void xenstore_record_dm_state(struct xs_handle *xs, const char
> *state)
> > +void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
> > {
> > char path[50];
> >
> > diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> > index afdf9c436a..31e9538a5c 100644
> > --- a/include/hw/xen/xen.h
> > +++ b/include/hw/xen/xen.h
> > @@ -9,6 +9,7 @@
> > */
> >
> > #include "exec/cpu-common.h"
> > +#include <xenstore.h>
>
> This is breaking a bunch of the builds and generally we try and avoid
> adding system includes in headers (apart from osdep.h) for this reason.
> In fact there is a comment just above to that fact.
>
> I think you can just add struct xs_handle to typedefs.h (or maybe just
> xen.h) and directly include xenstore.h in xen-all.c following the usual
> rules:
>
>
> https://qemu.readthedocs.io/en/latest/devel/style.html#include-directives
>
> It might be worth doing an audit to see what else is including xen.h
> needlessly or should be using sysemu/xen.h.
>
> >
> > /* xen-machine.c */
> > enum xen_mode {
> > @@ -31,5 +32,6 @@ qemu_irq *xen_interrupt_controller_init(void);
> > void xenstore_store_pv_console_info(int i, Chardev *chr);
> >
> > void xen_register_framebuffer(struct MemoryRegion *mr);
> > +void xenstore_record_dm_state(struct xs_handle *xs, const char *state);
> >
> > #endif /* QEMU_HW_XEN_H */
>
>
> --
> Alex Bennée
>
>
For considering:
I think this patch and some other changes done in "[PATCH v1 10/12] hw/arm:
introduce xenpv machine" (the opening of Xen interfaces and
calling xenstore_record_dm_state() in hw/arm/xen_arm.c:xen_init_ioreq())
could be avoided if we enable the Xen accelerator (either by passing "-M
xenpv,accel=xen" or by adding mc->default_machine_opts = "accel=xen";
to hw/arm/xen_arm.c:xen_arm_machine_class_init() or by some other method).
These actions are already done in accel/xen/xen-all.c:xen_init(). Please
note, that I am not too familiar with that code, so there might be nuances.
Besides that, Xen accelerator will be needed for the xen-mapcache to be in
use (this is needed for mapping guest memory), there are a few
xen_enabled() checks spreading around that code to perform Xen specific
actions.
--
Regards,
Oleksandr Tyshchenko
[-- Attachment #2: Type: text/html, Size: 4698 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
2022-10-27 9:14 ` Alex Bennée
2022-10-28 20:26 ` Oleksandr Tyshchenko
@ 2022-10-29 5:22 ` Garhwal, Vikram
2022-11-01 11:29 ` Alex Bennée
1 sibling, 1 reply; 50+ messages in thread
From: Garhwal, Vikram @ 2022-10-29 5:22 UTC (permalink / raw)
To: Alex Bennée
Cc: qemu-devel, Stabellini, Stefano, Stefano Stabellini,
Anthony Perard, Paul Durrant, xen-devel
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
Thanks, Alex, for reviewing this one. I built for all the archs and it was fine. Can you please share more about what environment builds are breaking? So, I can test the changes for v2.
Regards,
Vikram
From: Alex Bennée <alex.bennee@linaro.org>
Date: Thursday, October 27, 2022 at 2:24 AM
To: Garhwal, Vikram <vikram.garhwal@amd.com>
Cc: qemu-devel@nongnu.org <qemu-devel@nongnu.org>, Stabellini, Stefano <stefano.stabellini@amd.com>, Stefano Stabellini <sstabellini@kernel.org>, Anthony Perard <anthony.perard@citrix.com>, Paul Durrant <paul@xen.org>, xen-devel@lists.xenproject.org <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
Vikram Garhwal <vikram.garhwal@amd.com> writes:
> xenstore_record_dm_state() will also be used in aarch64 xenpv machine.
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> accel/xen/xen-all.c | 2 +-
> include/hw/xen/xen.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
> index 69aa7d018b..276625b78b 100644
> --- a/accel/xen/xen-all.c
> +++ b/accel/xen/xen-all.c
> @@ -100,7 +100,7 @@ void xenstore_store_pv_console_info(int i, Chardev *chr)
> }
>
>
> -static void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
> +void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
> {
> char path[50];
>
> diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> index afdf9c436a..31e9538a5c 100644
> --- a/include/hw/xen/xen.h
> +++ b/include/hw/xen/xen.h
> @@ -9,6 +9,7 @@
> */
>
> #include "exec/cpu-common.h"
> +#include <xenstore.h>
This is breaking a bunch of the builds and generally we try and avoid
adding system includes in headers (apart from osdep.h) for this reason.
In fact there is a comment just above to that fact.
I think you can just add struct xs_handle to typedefs.h (or maybe just
xen.h) and directly include xenstore.h in xen-all.c following the usual
rules:
https://qemu.readthedocs.io/en/latest/devel/style.html#include-directives
It might be worth doing an audit to see what else is including xen.h
needlessly or should be using sysemu/xen.h.
>
> /* xen-machine.c */
> enum xen_mode {
> @@ -31,5 +32,6 @@ qemu_irq *xen_interrupt_controller_init(void);
> void xenstore_store_pv_console_info(int i, Chardev *chr);
>
> void xen_register_framebuffer(struct MemoryRegion *mr);
> +void xenstore_record_dm_state(struct xs_handle *xs, const char *state);
>
> #endif /* QEMU_HW_XEN_H */
--
Alex Bennée
[-- Attachment #2: Type: text/html, Size: 5478 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
2022-10-28 20:26 ` Oleksandr Tyshchenko
@ 2022-10-29 5:36 ` Vikram Garhwal
0 siblings, 0 replies; 50+ messages in thread
From: Vikram Garhwal @ 2022-10-29 5:36 UTC (permalink / raw)
To: Oleksandr Tyshchenko, stefano.stabellini
Cc: qemu-devel, Stefano Stabellini, Anthony Perard, Paul Durrant,
Alex Bennée, xen-devel
Hi Oleksandr,
On 10/28/22 1:26 PM, Oleksandr Tyshchenko wrote:
>
>
> On Thu, Oct 27, 2022 at 12:24 PM Alex Bennée <alex.bennee@linaro.org>
> wrote:
>
> Hello all
>
>
>
> Vikram Garhwal <vikram.garhwal@amd.com> writes:
>
> > xenstore_record_dm_state() will also be used in aarch64 xenpv
> machine.
> >
> > Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> > ---
> > accel/xen/xen-all.c | 2 +-
> > include/hw/xen/xen.h | 2 ++
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
> > index 69aa7d018b..276625b78b 100644
> > --- a/accel/xen/xen-all.c
> > +++ b/accel/xen/xen-all.c
> > @@ -100,7 +100,7 @@ void xenstore_store_pv_console_info(int i,
> Chardev *chr)
> > }
> >
> >
> > -static void xenstore_record_dm_state(struct xs_handle *xs,
> const char *state)
> > +void xenstore_record_dm_state(struct xs_handle *xs, const char
> *state)
> > {
> > char path[50];
> >
> > diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> > index afdf9c436a..31e9538a5c 100644
> > --- a/include/hw/xen/xen.h
> > +++ b/include/hw/xen/xen.h
> > @@ -9,6 +9,7 @@
> > */
> >
> > #include "exec/cpu-common.h"
> > +#include <xenstore.h>
>
> This is breaking a bunch of the builds and generally we try and avoid
> adding system includes in headers (apart from osdep.h) for this
> reason.
> In fact there is a comment just above to that fact.
>
> I think you can just add struct xs_handle to typedefs.h (or maybe just
> xen.h) and directly include xenstore.h in xen-all.c following the
> usual
> rules:
>
> https://qemu.readthedocs.io/en/latest/devel/style.html#include-directives
>
> It might be worth doing an audit to see what else is including xen.h
> needlessly or should be using sysemu/xen.h.
>
> >
> > /* xen-machine.c */
> > enum xen_mode {
> > @@ -31,5 +32,6 @@ qemu_irq *xen_interrupt_controller_init(void);
> > void xenstore_store_pv_console_info(int i, Chardev *chr);
> >
> > void xen_register_framebuffer(struct MemoryRegion *mr);
> > +void xenstore_record_dm_state(struct xs_handle *xs, const char
> *state);
> >
> > #endif /* QEMU_HW_XEN_H */
>
>
> --
> Alex Bennée
>
>
>
> For considering:
> I think this patch and some other changes done in "[PATCH v1 10/12]
> hw/arm: introduce xenpv machine" (the opening of Xen interfaces and
> calling xenstore_record_dm_state() in hw/arm/xen_arm.c:xen_init_ioreq())
> could be avoided if we enable the Xen accelerator (either by passing
> "-M xenpv,accel=xen" or by adding mc->default_machine_opts =
> "accel=xen"; to hw/arm/xen_arm.c:xen_arm_machine_class_init() or by
> some other method).
> These actions are already done in accel/xen/xen-all.c:xen_init().
> Please note, that I am not too familiar with that code, so there might
> be nuances.
>
> Besides that, Xen accelerator will be needed for the xen-mapcache to
> be in use (this is needed for mapping guest memory), there are a few
> xen_enabled() checks spreading around that code to perform Xen
> specific actions.
>
Unfortunately, I am not that familiar with xen as accelerator function.
Let me check and get back to you.
> --
> Regards,
>
> Oleksandr Tyshchenko
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
2022-10-29 5:22 ` Garhwal, Vikram
@ 2022-11-01 11:29 ` Alex Bennée
0 siblings, 0 replies; 50+ messages in thread
From: Alex Bennée @ 2022-11-01 11:29 UTC (permalink / raw)
To: Garhwal, Vikram
Cc: qemu-devel, Stabellini, Stefano, Stefano Stabellini,
Anthony Perard, Paul Durrant, xen-devel
"Garhwal, Vikram" <vikram.garhwal@amd.com> writes:
> Thanks, Alex, for reviewing this one. I built for all the archs and it was fine. Can you please share more about what
> environment builds are breaking? So, I can test the changes for v2.
My cross build environment failed:
../../configure' '--disable-docs' '--disable-tools' '--cross-prefix=aarch64-linux-gnu-' '--enable-xen' '--target-list=i386-softmmu,x86_64-softmmu,arm-softmmu,aarch64-softmmu' '--disable-tpm'
On a Debian Bullseye with:
11:30:20 [root@zen:~] # dpkg -l libxen\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==========================-=======================-============-====================================================
ii libxen-dev:arm64 4.14.5+24-g87d90d511c-1 arm64 Public headers and libs for Xen
ii libxencall1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime library - libxencall
ii libxencall1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime library - libxencall
ii libxendevicemodel1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - libxendevicemodel
ii libxendevicemodel1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - libxendevicemodel
ii libxenevtchn1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - libxenevtchn
ii libxenevtchn1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - libxenevtchn
ii libxenforeignmemory1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - libxenforeignmemory
ii libxenforeignmemory1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - libxenforeignmemory
ii libxengnttab1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - libxengnttab
ii libxengnttab1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - libxengnttab
ii libxenhypfs1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime library - libxenhypfs
ii libxenhypfs1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime library - libxenhypfs
ii libxenmisc4.14:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - miscellaneous, versioned ABI
ii libxenmisc4.14:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - miscellaneous, versioned ABI
ii libxenstore3.0:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - libxenstore
ii libxenstore3.0:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - libxenstore
ii libxentoolcore1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - libxentoolcore
ii libxentoolcore1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - libxentoolcore
ii libxentoollog1:amd64 4.14.5+24-g87d90d511c-1 amd64 Xen runtime libraries - libxentoollog
ii libxentoollog1:arm64 4.14.5+24-g87d90d511c-1 arm64 Xen runtime libraries - libxentoollog
But also a bunch of cross builds on the CI system:
https://gitlab.com/stsquad/qemu/-/pipelines/677956972/failures
>
>
>
> Regards,
>
> Vikram
>
>
>
> From: Alex Bennée <alex.bennee@linaro.org>
> Date: Thursday, October 27, 2022 at 2:24 AM
> To: Garhwal, Vikram <vikram.garhwal@amd.com>
> Cc: qemu-devel@nongnu.org <qemu-devel@nongnu.org>, Stabellini, Stefano <stefano.stabellini@amd.com>, Stefano
> Stabellini <sstabellini@kernel.org>, Anthony Perard <anthony.perard@citrix.com>, Paul Durrant <paul@xen.org>,
> xen-devel@lists.xenproject.org <xen-devel@lists.xenproject.org>
> Subject: Re: [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state
>
> Vikram Garhwal <vikram.garhwal@amd.com> writes:
>
>> xenstore_record_dm_state() will also be used in aarch64 xenpv machine.
>>
>> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
>> ---
>> accel/xen/xen-all.c | 2 +-
>> include/hw/xen/xen.h | 2 ++
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
>> index 69aa7d018b..276625b78b 100644
>> --- a/accel/xen/xen-all.c
>> +++ b/accel/xen/xen-all.c
>> @@ -100,7 +100,7 @@ void xenstore_store_pv_console_info(int i, Chardev *chr)
>> }
>>
>>
>> -static void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
>> +void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
>> {
>> char path[50];
>>
>> diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
>> index afdf9c436a..31e9538a5c 100644
>> --- a/include/hw/xen/xen.h
>> +++ b/include/hw/xen/xen.h
>> @@ -9,6 +9,7 @@
>> */
>>
>> #include "exec/cpu-common.h"
>> +#include <xenstore.h>
>
> This is breaking a bunch of the builds and generally we try and avoid
> adding system includes in headers (apart from osdep.h) for this reason.
> In fact there is a comment just above to that fact.
>
> I think you can just add struct xs_handle to typedefs.h (or maybe just
> xen.h) and directly include xenstore.h in xen-all.c following the usual
> rules:
>
> https://qemu.readthedocs.io/en/latest/devel/style.html#include-directives
>
> It might be worth doing an audit to see what else is including xen.h
> needlessly or should be using sysemu/xen.h.
>
>>
>> /* xen-machine.c */
>> enum xen_mode {
>> @@ -31,5 +32,6 @@ qemu_irq *xen_interrupt_controller_init(void);
>> void xenstore_store_pv_console_info(int i, Chardev *chr);
>>
>> void xen_register_framebuffer(struct MemoryRegion *mr);
>> +void xenstore_record_dm_state(struct xs_handle *xs, const char *state);
>>
>> #endif /* QEMU_HW_XEN_H */
--
Alex Bennée
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/
2022-10-19 14:53 ` Paul Durrant
@ 2022-12-01 20:25 ` Garhwal, Vikram
0 siblings, 0 replies; 50+ messages in thread
From: Garhwal, Vikram @ 2022-12-01 20:25 UTC (permalink / raw)
To: Paul Durrant, qemu-devel
Cc: Stabellini, Stefano, Michael S. Tsirkin, Marcel Apfelbaum,
Paolo Bonzini, Richard Henderson, Eduardo Habkost,
Stefano Stabellini, Anthony Perard, open list:X86 Xen CPUs
[-- Attachment #1: Type: text/plain, Size: 4444 bytes --]
Hi Paul,
From: Paul Durrant <xadimgnik@gmail.com>
Date: Wednesday, October 19, 2022 at 7:54 AM
To: Garhwal, Vikram <vikram.garhwal@amd.com>, qemu-devel@nongnu.org <qemu-devel@nongnu.org>
Cc: Stabellini, Stefano <stefano.stabellini@amd.com>, Michael S. Tsirkin <mst@redhat.com>, Marcel Apfelbaum <marcel.apfelbaum@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <richard.henderson@linaro.org>, Eduardo Habkost <eduardo@habkost.net>, Stefano Stabellini <sstabellini@kernel.org>, Anthony Perard <anthony.perard@citrix.com>, open list:X86 Xen CPUs <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/
On 15/10/2022 06:07, Vikram Garhwal wrote:
> xen-mapcache.c contains common functions which can be used for enabling Xen on
> aarch64 with IOREQ handling. Moving it out from hw/i386/xen to hw/xen to make it
> accessible for both aarch64 and x86.
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
> hw/i386/meson.build | 1 +
> hw/i386/xen/meson.build | 1 -
> hw/i386/xen/trace-events | 5 -----
> hw/xen/meson.build | 4 ++++
> hw/xen/trace-events | 5 +++++
> hw/{i386 => }/xen/xen-mapcache.c | 0
> 6 files changed, 10 insertions(+), 6 deletions(-)
> rename hw/{i386 => }/xen/xen-mapcache.c (100%)
>
> diff --git a/hw/i386/meson.build b/hw/i386/meson.build
> index 213e2e82b3..cfdbfdcbcb 100644
> --- a/hw/i386/meson.build
> +++ b/hw/i386/meson.build
> @@ -33,5 +33,6 @@ subdir('kvm')
> subdir('xen')
>
> i386_ss.add_all(xenpv_ss)
> +i386_ss.add_all(xen_ss)
>
> hw_arch += {'i386': i386_ss}
> diff --git a/hw/i386/xen/meson.build b/hw/i386/xen/meson.build
> index be84130300..2fcc46e6ca 100644
> --- a/hw/i386/xen/meson.build
> +++ b/hw/i386/xen/meson.build
> @@ -1,6 +1,5 @@
> i386_ss.add(when: 'CONFIG_XEN', if_true: files(
> 'xen-hvm.c',
> - 'xen-mapcache.c',
> 'xen_apic.c',
> 'xen_platform.c',
> 'xen_pvdevice.c',
> diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
> index 5d6be61090..a0c89d91c4 100644
> --- a/hw/i386/xen/trace-events
> +++ b/hw/i386/xen/trace-events
> @@ -21,8 +21,3 @@ xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
> cpu_ioreq_config_read(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
> cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t reg, uint32_t size, uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
>
> -# xen-mapcache.c
> -xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
> -xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
> -xen_map_cache_return(void* ptr) "%p"
> -
> diff --git a/hw/xen/meson.build b/hw/xen/meson.build
> index ae0ace3046..19d0637c46 100644
> --- a/hw/xen/meson.build
> +++ b/hw/xen/meson.build
> @@ -22,3 +22,7 @@ else
> endif
>
> specific_ss.add_all(when: ['CONFIG_XEN', xen], if_true: xen_specific_ss)
> +
> +xen_ss = ss.source_set()
> +
> +xen_ss.add(when: 'CONFIG_XEN', if_true: files('xen-mapcache.c'))
Curious as to why you couldn't just add this to the softmmu_ss list above?
Moving it to softmmu_ss breaks the build as it builds without XEN_CONFIG. I think xen option in “softmmu_ss.add(when: ['CONFIG_XEN', xen], if_true: files” is problem here. I see below error:
/sysemu/xen-mapcache.h:16:8: error: attempt to use poisoned "CONFIG_XEN"
#ifdef CONFIG_XEN
^
../hw/xen/xen-mapcache.c:106:6: error: redefinition of 'xen_map_cache_init'
void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
Paul
> diff --git a/hw/xen/trace-events b/hw/xen/trace-events
> index 3da3fd8348..2c8f238f42 100644
> --- a/hw/xen/trace-events
> +++ b/hw/xen/trace-events
> @@ -41,3 +41,8 @@ xs_node_vprintf(char *path, char *value) "%s %s"
> xs_node_vscanf(char *path, char *value) "%s %s"
> xs_node_watch(char *path) "%s"
> xs_node_unwatch(char *path) "%s"
> +
> +# xen-mapcache.c
> +xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
> +xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
> +xen_map_cache_return(void* ptr) "%p"
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
> similarity index 100%
> rename from hw/i386/xen/xen-mapcache.c
> rename to hw/xen/xen-mapcache.c
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 21778 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-10-16 17:47 ` Julien Grall
2022-10-18 1:26 ` Stefano Stabellini
2022-10-27 8:37 ` Alex Bennée
@ 2022-12-02 3:24 ` Garhwal, Vikram
2022-12-02 9:53 ` Julien Grall
2 siblings, 1 reply; 50+ messages in thread
From: Garhwal, Vikram @ 2022-12-02 3:24 UTC (permalink / raw)
To: Julien Grall, qemu-devel
Cc: Stabellini, Stefano, Peter Maydell, Stefano Stabellini,
Anthony Perard, Paul Durrant, open list:ARM TCG CPUs,
open list:X86 Xen CPUs
[-- Attachment #1: Type: text/plain, Size: 7489 bytes --]
Hi Julien,
From: Julien Grall <julien@xen.org>
Date: Sunday, October 16, 2022 at 10:48 AM
To: Garhwal, Vikram <vikram.garhwal@amd.com>, qemu-devel@nongnu.org <qemu-devel@nongnu.org>
Cc: Stabellini, Stefano <stefano.stabellini@amd.com>, Peter Maydell <peter.maydell@linaro.org>, Stefano Stabellini <sstabellini@kernel.org>, Anthony Perard <anthony.perard@citrix.com>, Paul Durrant <paul@xen.org>, open list:ARM TCG CPUs <qemu-arm@nongnu.org>, open list:X86 Xen CPUs <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
Hi,
There seem to be some missing patches on xen-devel (including the cover
letter). Is that expected?
Not sure what went wrong there. I can see all of these on QEMU-devel. Perhaps xen-devel is not in maintainer’s list for all the xen files?
On 15/10/2022 06:07, Vikram Garhwal wrote:
> Add a new machine xenpv which creates a IOREQ server to register/connect with
> Xen Hypervisor.
I don't like the name 'xenpv' because it doesn't convey the fact that
some of the HW may be emulated rather than para-virtualized. In fact one
may only want to use for emulating devices.
Potential name would be 'xen-arm' or re-using 'virt' but with
'accel=xen' to select a Xen layout.
>
> Xen IOREQ connection expect the TARGET_PAGE_SIZE to 4096, and the xenpv machine
> on ARM will have no CPU definitions. We need to define TARGET_PAGE_SIZE
> appropriately ourselves.
>
> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
> TPM emulator and connects to swtpm running on host machine via chardev socket
> and support TPM functionalities for a guest domain.
>
> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
> -tpmdev emulator,id=tpm0,chardev=chrtpm \
>
> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
> provides access to TPM functionality over socket, chardev and CUSE interface.
> Github repo: https://github.com/stefanberger/swtpm
> Example for starting swtpm on host machine:
> mkdir /tmp/vtpm2
> swtpm socket --tpmstate dir=/tmp/vtpm2 \
> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
I see patches for QEMU but not Xen. How can this be tested with existing
Xen? Will libxl ever create QEMU?
Will send the patch for libxl Xen separately.
[...]
> +static int xen_init_ioreq(XenIOState *state, unsigned int max_cpus)
> +{
> + xen_dmod = xendevicemodel_open(0, 0);
> + xen_xc = xc_interface_open(0, 0, 0);
> +
> + if (xen_xc == NULL) {
You are checking xen_xc but not xen_dmod. Why?
> + perror("xen: can't open xen interface\n");
> + return -1;
> + }
> +
> + xen_fmem = xenforeignmemory_open(0, 0);
> + if (xen_fmem == NULL) {
> + perror("xen: can't open xen fmem interface\n");
> + xc_interface_close(xen_xc);
> + return -1;
> + }
> +
> + xen_register_ioreq(state, max_cpus, xen_memory_listener);
> +
> + xenstore_record_dm_state(xenstore, "running");
> +
> + return 0;
> +}
> +
> +static void xen_enable_tpm(void)
> +{
> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */
> +#ifdef CONFIG_TPM
> + Error *errp = NULL;
> + DeviceState *dev;
> + SysBusDevice *busdev;
> +
> + TPMBackend *be = qemu_find_tpm_be("tpm0");
> + if (be == NULL) {
> + DPRINTF("Couldn't fine the backend for tpm0\n");
> + return;
> + }
> + dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
> + object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
> + object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
> + busdev = SYS_BUS_DEVICE(dev);
> + sysbus_realize_and_unref(busdev, &error_fatal);
> + sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
I can't find where GUEST_TPM_BASE is defined. But then the guest memory
layout is not expected to be stable. With your current approach, it
means QEMU would need to be rebuilt for every Xen version. Is it what we
want?
I cannot think of better way to do this. Either we add the the def here or rebuild it if GUEST_TPM_BASE changes for each xen version.
> +
> + DPRINTF("Connected tpmdev at address 0x%lx\n", GUEST_TPM_BASE);
> +#endif
> +}
> +
> +static void xen_arm_init(MachineState *machine)
> +{
> + XenArmState *xam = XEN_ARM(machine);
> +
> + xam->state = g_new0(XenIOState, 1);
> +
> + if (xen_init_ioreq(xam->state, machine->smp.cpus)) {
> + return;
In another patch, you said the IOREQ would be optional. IHMO, I think
this is a bad idea to register it by default because one may only want
to use PV drivers. Registering IOREQ will add unnecessary overhead in Xen.
Furthermore, it means that someone selecting TPM but Xen is not built
with CONFIG_IOREQ=y (BTW This is still a tech preview but there are
security holes on Arm...) will not get an error. Instead, the OS will
until it crashes when trying to access the TPM.
Overall I think it would be better if IOREQ is only registered when a
device requires (like TPM) it *and* throw an error if there is a problem
during the initialization.
> + } > +
> + xen_enable_tpm();
> +
> + return;
> +}
> +
> +static void xen_arm_machine_class_init(ObjectClass *oc, void *data)
> +{
> +
> + MachineClass *mc = MACHINE_CLASS(oc);
> + mc->desc = "Xen Para-virtualized PC";
> + mc->init = xen_arm_init;
> + mc->max_cpus = 1;
> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
Shouldn't this be protected with #ifdef CONFIG_TPM?
> +}
> +
> +static const TypeInfo xen_arm_machine_type = {
> + .name = TYPE_XEN_ARM,
> + .parent = TYPE_MACHINE,
> + .class_init = xen_arm_machine_class_init,
> + .instance_size = sizeof(XenArmState),
> +};
> +
> +static void xen_arm_machine_register_types(void)
> +{
> + type_register_static(&xen_arm_machine_type);
> +}
> +
> +type_init(xen_arm_machine_register_types)
> diff --git a/include/hw/arm/xen_arch_hvm.h b/include/hw/arm/xen_arch_hvm.h
> new file mode 100644
> index 0000000000..f645dfec28
> --- /dev/null
> +++ b/include/hw/arm/xen_arch_hvm.h
> @@ -0,0 +1,12 @@
> +#ifndef HW_XEN_ARCH_ARM_HVM_H
> +#define HW_XEN_ARCH_ARM_HVM_H
> +
> +#include <xen/hvm/ioreq.h>
> +void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> +void arch_xen_set_memory(XenIOState *state,
> + MemoryRegionSection *section,
> + bool add);
> +
> +#undef TARGET_PAGE_SIZE
I am a bit puzzled with this #undef. In the commit message you said that
there will be no CPU definition. So the implications is this should not
be defined.
If it is defined, then what guarantees that all the source will use the
correct value?
> +#define TARGET_PAGE_SIZE 4096
It would be better to use XC_PAGE_SIZE (or similar) rather than
hardcoding it.
Corrected this and sent a v2.
> +#endif
> diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
> index 26674648d8..c7c515220d 100644
> --- a/include/hw/xen/arch_hvm.h
> +++ b/include/hw/xen/arch_hvm.h
> @@ -1,3 +1,5 @@
> #if defined(TARGET_I386) || defined(TARGET_X86_64)
> #include "hw/i386/xen_arch_hvm.h"
> +#elif defined(TARGET_ARM) || defined(TARGET_ARM_64)
> +#include "hw/arm/xen_arch_hvm.h"
> #endif
Cheers,
--
Julien Grall
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 26085 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
2022-12-02 3:24 ` Garhwal, Vikram
@ 2022-12-02 9:53 ` Julien Grall
0 siblings, 0 replies; 50+ messages in thread
From: Julien Grall @ 2022-12-02 9:53 UTC (permalink / raw)
To: Garhwal, Vikram, qemu-devel
Cc: Stabellini, Stefano, Peter Maydell, Stefano Stabellini,
Anthony Perard, Paul Durrant, open list:ARM TCG CPUs,
open list:X86 Xen CPUs
On 02/12/2022 03:24, Garhwal, Vikram wrote:
> Hi Julien,
Hi Vikram,
I am having trouble to differentiate your answers from my remark. For
instance...
> From: Julien Grall <julien@xen.org>
> Date: Sunday, October 16, 2022 at 10:48 AM
> To: Garhwal, Vikram <vikram.garhwal@amd.com>, qemu-devel@nongnu.org <qemu-devel@nongnu.org>
> Cc: Stabellini, Stefano <stefano.stabellini@amd.com>, Peter Maydell <peter.maydell@linaro.org>, Stefano Stabellini <sstabellini@kernel.org>, Anthony Perard <anthony.perard@citrix.com>, Paul Durrant <paul@xen.org>, open list:ARM TCG CPUs <qemu-arm@nongnu.org>, open list:X86 Xen CPUs <xen-devel@lists.xenproject.org>
> Subject: Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
> Hi,
>
> There seem to be some missing patches on xen-devel (including the cover
> letter). Is that expected?
> Not sure what went wrong there. I can see all of these on QEMU-devel. Perhaps xen-devel is not in maintainer’s list for all the xen files?
>
>
> On 15/10/2022 06:07, Vikram Garhwal wrote:
>> Add a new machine xenpv which creates a IOREQ server to register/connect with
>> Xen Hypervisor.
>
> I don't like the name 'xenpv' because it doesn't convey the fact that
> some of the HW may be emulated rather than para-virtualized. In fact one
> may only want to use for emulating devices.
>
> Potential name would be 'xen-arm' or re-using 'virt' but with
> 'accel=xen' to select a Xen layout.
>
>>
>> Xen IOREQ connection expect the TARGET_PAGE_SIZE to 4096, and the xenpv machine
>> on ARM will have no CPU definitions. We need to define TARGET_PAGE_SIZE
>> appropriately ourselves.
>>
>> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device, adds a
>> TPM emulator and connects to swtpm running on host machine via chardev socket
>> and support TPM functionalities for a guest domain.
>>
>> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
>> -chardev socket,id=chrtpm,path=/tmp/myvtpm2/swtpm-sock \
>> -tpmdev emulator,id=tpm0,chardev=chrtpm \
>>
>> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on libtpms and
>> provides access to TPM functionality over socket, chardev and CUSE interface.
>> Github repo: https://github.com/stefanberger/swtpm
>> Example for starting swtpm on host machine:
>> mkdir /tmp/vtpm2
>> swtpm socket --tpmstate dir=/tmp/vtpm2 \
>> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock &
>
> I see patches for QEMU but not Xen. How can this be tested with existing
> Xen? Will libxl ever create QEMU?
> Will send the patch for libxl Xen separately.
... the first two lines are my remarks and the 3rd is your answer. Can
you configure your e-mail client to do proper quoting?
[...]
>> + dev = qdev_new(TYPE_TPM_TIS_SYSBUS);
>> + object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp);
>> + object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp);
>> + busdev = SYS_BUS_DEVICE(dev);
>> + sysbus_realize_and_unref(busdev, &error_fatal);
>> + sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
>
> I can't find where GUEST_TPM_BASE is defined. But then the guest memory
> layout is not expected to be stable. With your current approach, it
> means QEMU would need to be rebuilt for every Xen version. Is it what we
> want?
> I cannot think of better way to do this. Either we add the the def here or rebuild it if GUEST_TPM_BASE changes for each xen version.
The alternative would be to specify the address on the QEMU command
line. The advantage is you could build a system where each guests have
different layout.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2022-12-02 9:54 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-15 5:07 [PATCH v1 00/12] Introduce xenpv machine for arm architecture Vikram Garhwal
2022-10-15 5:07 ` [PATCH v1 01/12] hw/xen: Correct build config for xen_pt_stub Vikram Garhwal
2022-10-19 14:46 ` Paul Durrant
2022-10-26 19:01 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 02/12] hw/i386/xen/: move xen-mapcache.c to hw/xen/ Vikram Garhwal
2022-10-19 14:53 ` Paul Durrant
2022-12-01 20:25 ` Garhwal, Vikram
2022-10-15 5:07 ` [PATCH v1 03/12] hw/i386/xen: rearrange xen_hvm_init_pc Vikram Garhwal
2022-10-19 14:59 ` Paul Durrant
2022-10-15 5:07 ` [PATCH v1 04/12] hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOState Vikram Garhwal
2022-10-19 15:56 ` Paul Durrant
2022-10-19 16:00 ` Paul Durrant
2022-10-27 8:59 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 05/12] hw/i386/xen/xen-hvm: create arch_handle_ioreq and arch_xen_set_memory Vikram Garhwal
2022-10-19 16:09 ` Paul Durrant
2022-10-27 9:02 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 06/12] xen-hvm: move common functions to hw/xen/xen-hvm-common.c Vikram Garhwal
2022-10-16 18:07 ` Julien Grall
2022-10-19 16:16 ` Paul Durrant
2022-10-19 23:12 ` Garhwal, Vikram
2022-10-15 5:07 ` [PATCH v1 07/12] include/hw/xen/xen_common: return error from xen_create_ioreq_server Vikram Garhwal
2022-10-16 17:53 ` Julien Grall
2022-10-15 5:07 ` [PATCH v1 08/12] hw/xen/xen-hvm-common: skip ioreq creation on ioreq registration failure Vikram Garhwal
2022-10-27 8:46 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 09/12] accel/xen/xen-all: export xenstore_record_dm_state Vikram Garhwal
2022-10-19 16:20 ` Paul Durrant
2022-10-27 9:14 ` Alex Bennée
2022-10-28 20:26 ` Oleksandr Tyshchenko
2022-10-29 5:36 ` Vikram Garhwal
2022-10-29 5:22 ` Garhwal, Vikram
2022-11-01 11:29 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 10/12] hw/arm: introduce xenpv machine Vikram Garhwal
2022-10-16 17:47 ` Julien Grall
2022-10-18 1:26 ` Stefano Stabellini
2022-10-18 8:24 ` Julien Grall
2022-10-19 0:15 ` Stefano Stabellini
2022-10-19 9:49 ` Julien Grall
2022-10-27 8:37 ` Alex Bennée
2022-12-02 3:24 ` Garhwal, Vikram
2022-12-02 9:53 ` Julien Grall
2022-10-27 8:02 ` Alex Bennée
2022-10-28 17:57 ` Julien Grall
2022-10-28 19:05 ` Oleksandr Tyshchenko
2022-10-27 8:40 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 11/12] meson.build: enable xenpv machine build for ARM Vikram Garhwal
2022-10-27 9:11 ` Alex Bennée
2022-10-15 5:07 ` [PATCH v1 12/12] meson.build: do not set have_xen_pci_passthrough for aarch64 targets Vikram Garhwal
2022-10-27 9:14 ` Alex Bennée
2022-10-27 8:26 ` [PATCH v1 00/12] Introduce xenpv machine for arm architecture Alex Bennée
2022-10-27 9:24 ` Alex Bennée
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.