* [PATCH RESEND v6 00/36] Initial support for multi-process qemu
@ 2020-04-23 4:13 elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset elena.ufimtseva
` (38 more replies)
0 siblings, 39 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Hello
This is a resend of v6 patchset since we regrettably omitted few comments
from v5 review in the previously sent series
(see in https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg00828.html).
We also run more tests and fixed the build errors that were found in v6.
Started with the presentation in October 2017 made by Marc-Andre (Red Hat)
and Konrad Wilk (Oracle) [1], and continued by Jag's BoF at KVM Forum 2018,
the multi-process project is now available and presented in this patchset.
This first series enables the emulation of lsi53c895a in a separate process.
We posted the Proof Of Concept patches [2] before the BoF session in 2018.
Subsequently, we posted RFC v1 [3], RFC v2 [4], RFC v3 [5], RFC v4 [6]
and v5 [7] of the patch series.
This is v6 of the patch series and it addresses the previous feedback from
the community.
To make easier to review of the series, we have separated out some of the
patches and will send them in the separate series. As per conversation we
had during the last community call, the live migration support is taken out
from this series as well as asynchronous communication.
The changes include the elimination of fork/exec of the remote process
and instead using the orchestrator which is implemented in this series as
a python script.
Following people contributed to this patchset:
John G Johnson <john.g.johnson@oracle.com>
Jagannathan Raman <jag.raman@oracle.com>
Elena Ufimtseva <elena.ufimtseva@oracle.com>
Kanth Ghatraju <kanth.ghatraju@oracle.com>
Konrad Wilk <konrad.wilk@oracle.com>
For full concept writeup about QEMU disaggregation, refer to
docs/devel/qemu-multiprocess.rst. Please refer to
docs/qemu-multiprocess.txt for usage information.
We will post separate patchsets for the following improvements for
the experimental Qemu multi-process:
- Live migration;
- Asynchronous communication channel;
- Libvirt support;
We welcome all your ideas, concerns, and questions for this patchset.
Testing results
There is an error in travis-ci build test which does not get reproduced.
TEST iotest-qcow2: 041 [fail]
QEMU -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64" -nodefaults -display none -accel qtest
QEMU_IMG -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-img"
QEMU_IO -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2
QEMU_NBD -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-nbd"
IMGFMT -- qcow2 (compat=1.1)
IMGPROTO -- file
PLATFORM -- Linux/x86_64 travis-job-fc4e2553-b470-4a8b-812e-a4fcf8ba094f 5.0.0-1031-gcp
TEST_DIR -- /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch
SOCK_DIR -- /tmp/tmp.LOmYANt5Od
SOCKET_SCM_HELPER -- /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/socket_scm_helper
--- /home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/041.out 2020-04-22 00:17:23.701844698 +0000
+++ /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/041.out.bad 2020-04-22 00:24:39.234343858 +0000
@@ -1,5 +1,29 @@
-..............................................................................................
+........................FF....................................................................
+======================================================================
+FAIL: test_with_other_parent (__main__.TestRepairQuorum)
+----------------------------------------------------------------------
+Traceback (most recent call last):
+ File "041", line 1049, in test_with_other_parent
+ self.assert_qmp(result, 'return', {})
+ File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 821, in assert_qmp
+ result = self.dictpath(d, path)
+ File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 797, in dictpath
+ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d)))
+AssertionError: failed path traversal for "return" in "{'error': {'class': 'GenericError', 'desc': "UNIX socket path '/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch/nbd.sock' is too long"}}"
a
+
Not run: 220 259
Failures: 041
Failed 1 of 116 iotests
/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/Makefile.include:848: recipe for target 'check-tests/check-block.sh' failed
make: *** [check-tests/check-block.sh] Error 1
The command "if [ "$BUILD_RC" -eq 0 ] ; then
${TEST_CMD} ;
else
$(exit $BUILD_RC);
fi
Thank you!
[1]: http://events17.linuxfoundation.org/sites/events/files/slides/KVM%20FORUM%20multi-process.pdf
[1]: https://www.youtube.com/watch?v=Kq1-coHh7lg
[2]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg566538.html
[3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg602285.html
[4]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg624877.html
[5]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg642000.html
[6]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg655118.html
[7]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg682429.html
--
2.25.GIT
Elena Ufimtseva (18):
multi-process: Refactor machine_init and exit notifiers
command-line: refractor parser code
multi-process: Refactor chardev functions out of vl.c
multi-process: Refactor monitor functions out of vl.c
multi-process: add a command line option for debug file
multi-process: introduce proxy object
multi-process: Forward PCI config space acceses to the remote process
multi-process: Introduce build flags to separate remote process code
multi-process: add parse_cmdline in remote process
multi-process: add support to parse device option
multi-process: send heartbeat messages to remote
multi-process: handle heartbeat messages in remote process
multi-process: perform device reset in the remote process
multi-process/mon: choose HMP commands based on target
multi-process/mon: stub functions to enable QMP module for remote
process
multi-process/mon: enable QMP module support in the remote process
multi-process/mon: Initialize QMP module for remote processes
multi-process: add configure and usage information
Jagannathan Raman (17):
memory: alloc RAM from file at offset
monitor: destaticize HMP commands
multi-process: Add stub functions to facilitate build of multi-process
multi-process: Add config option for multi-process QEMU
multi-process: build system for remote device process
multi-process: define mpqemu-link object
multi-process: add functions to synchronize proxy and remote endpoints
multi-process: setup PCI host bridge for remote device
multi-process: setup a machine object for remote device process
multi-process: setup memory manager for remote device
multi-process: remote process initialization
multi-process: Initialize Proxy Object's communication channel
multi-process: Connect Proxy Object with device in the remote process
multi-process: PCI BAR read/write handling for proxy & remote
endpoints
multi-process: Synchronize remote memory
multi-process: create IOHUB object to handle irq
multi-process: Retrieve PCI info from remote process
John G Johnson (1):
multi-process: add the concept description to
docs/devel/qemu-multiprocess
MAINTAINERS | 39 ++
Makefile | 2 +
Makefile.objs | 41 ++
Makefile.target | 104 ++-
accel/Makefile.objs | 2 +
accel/stubs/kvm-stub.c | 5 +
accel/stubs/tcg-stub.c | 108 +++
backends/Makefile.objs | 2 +
block/Makefile.objs | 5 +
block/monitor/Makefile.objs | 2 +
chardev/char.c | 14 +
configure | 15 +
docs/devel/index.rst | 1 +
docs/devel/multi-process.rst | 957 +++++++++++++++++++++++++++
docs/multi-process.rst | 85 +++
exec.c | 31 +-
hmp-commands-info.hx | 10 +
hmp-commands.hx | 25 +-
hw/Makefile.objs | 7 +
hw/block/Makefile.objs | 2 +
hw/core/Makefile.objs | 19 +
hw/nvram/Makefile.objs | 2 +
hw/pci/Makefile.objs | 4 +
hw/proxy/memory-sync.c | 217 ++++++
hw/proxy/qemu-proxy.c | 488 ++++++++++++++
hw/scsi/Makefile.objs | 2 +
include/chardev/char.h | 2 +
include/exec/address-spaces.h | 2 +
include/exec/ram_addr.h | 4 +-
include/hw/pci/pci_ids.h | 3 +
include/hw/proxy/memory-sync.h | 37 ++
include/hw/proxy/qemu-proxy.h | 79 +++
include/io/mpqemu-link.h | 192 ++++++
include/monitor/monitor.h | 3 +
include/qemu-common.h | 8 +
include/qemu-parse.h | 42 ++
include/qemu/log.h | 1 +
include/qemu/mmap-alloc.h | 3 +-
include/remote/iohub.h | 50 ++
include/remote/machine.h | 32 +
include/remote/memory.h | 20 +
include/remote/pcihost.h | 45 ++
include/sysemu/sysemu.h | 2 +
io/Makefile.objs | 2 +
io/mpqemu-link.c | 407 ++++++++++++
memory.c | 2 +-
migration/Makefile.objs | 2 +
monitor/Makefile.objs | 4 +
monitor/misc.c | 84 +--
monitor/monitor-internal.h | 38 ++
monitor/monitor.c | 37 ++
qapi/Makefile.objs | 2 +
qemu-parse.c | 93 +++
qom/Makefile.objs | 4 +
remote/Makefile.objs | 6 +
remote/iohub.c | 148 +++++
remote/machine.c | 99 +++
remote/memory.c | 63 ++
remote/pcihost.c | 64 ++
remote/remote-common.h | 21 +
remote/remote-main.c | 379 +++++++++++
remote/remote-opts.c | 96 +++
remote/remote-opts.h | 15 +
rules.mak | 2 +-
scripts/hxtool | 35 +-
scripts/mpqemu-launcher-perf-mode.py | 92 +++
scripts/mpqemu-launcher.py | 53 ++
softmmu/vl.c | 175 +----
stubs/Makefile.objs | 3 +
stubs/audio.c | 12 +
stubs/gdbstub.c | 23 +
stubs/get-fd.c | 10 +
stubs/machine-init-add.c | 7 +
stubs/machine-init-done.c | 5 +-
stubs/machine-init-remove.c | 8 +
stubs/migration.c | 162 +++++
stubs/monitor.c | 85 ++-
stubs/net-stub.c | 100 +++
stubs/qapi-misc.c | 41 ++
stubs/qapi-target.c | 56 ++
stubs/replay.c | 18 +
stubs/ui-stub.c | 130 ++++
stubs/vl-stub.c | 171 +++++
stubs/vmstate.c | 19 +
stubs/xen-mapcache.c | 22 +
ui/Makefile.objs | 2 +
util/Makefile.objs | 2 +
util/log.c | 2 +
util/machine-notify.c | 69 ++
util/mmap-alloc.c | 7 +-
util/oslib-posix.c | 2 +-
91 files changed, 5356 insertions(+), 237 deletions(-)
create mode 100644 docs/devel/multi-process.rst
create mode 100644 docs/multi-process.rst
create mode 100644 hw/proxy/memory-sync.c
create mode 100644 hw/proxy/qemu-proxy.c
create mode 100644 include/hw/proxy/memory-sync.h
create mode 100644 include/hw/proxy/qemu-proxy.h
create mode 100644 include/io/mpqemu-link.h
create mode 100644 include/qemu-parse.h
create mode 100644 include/remote/iohub.h
create mode 100644 include/remote/machine.h
create mode 100644 include/remote/memory.h
create mode 100644 include/remote/pcihost.h
create mode 100644 io/mpqemu-link.c
create mode 100644 qemu-parse.c
create mode 100644 remote/Makefile.objs
create mode 100644 remote/iohub.c
create mode 100644 remote/machine.c
create mode 100644 remote/memory.c
create mode 100644 remote/pcihost.c
create mode 100644 remote/remote-common.h
create mode 100644 remote/remote-main.c
create mode 100644 remote/remote-opts.c
create mode 100644 remote/remote-opts.h
mode change 100644 => 100755 scripts/hxtool
create mode 100755 scripts/mpqemu-launcher-perf-mode.py
create mode 100755 scripts/mpqemu-launcher.py
create mode 100644 stubs/audio.c
create mode 100644 stubs/get-fd.c
create mode 100644 stubs/machine-init-add.c
create mode 100644 stubs/machine-init-remove.c
create mode 100644 stubs/migration.c
create mode 100644 stubs/net-stub.c
create mode 100644 stubs/qapi-misc.c
create mode 100644 stubs/qapi-target.c
create mode 100644 stubs/ui-stub.c
create mode 100644 stubs/vl-stub.c
create mode 100644 stubs/xen-mapcache.c
create mode 100644 util/machine-notify.c
--
2.25.GIT
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 8:26 ` Stefan Hajnoczi
2020-05-12 8:48 ` Daniel P. Berrangé
2020-04-23 4:13 ` [PATCH RESEND v6 02/36] multi-process: Refactor machine_init and exit notifiers elena.ufimtseva
` (37 subsequent siblings)
38 siblings, 2 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Allow RAM MemoryRegion to be created from an offset in a file, instead
of allocating at offset of 0 by default. This is needed to synchronize
RAM between QEMU & remote process.
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
exec.c | 11 +++++++----
include/exec/ram_addr.h | 2 +-
include/qemu/mmap-alloc.h | 3 ++-
memory.c | 2 +-
util/mmap-alloc.c | 7 ++++---
util/oslib-posix.c | 2 +-
6 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/exec.c b/exec.c
index 2874bb5088..d0ac9545f4 100644
--- a/exec.c
+++ b/exec.c
@@ -1801,6 +1801,7 @@ static void *file_ram_alloc(RAMBlock *block,
ram_addr_t memory,
int fd,
bool truncate,
+ off_t offset,
Error **errp)
{
void *area;
@@ -1851,7 +1852,8 @@ static void *file_ram_alloc(RAMBlock *block,
}
area = qemu_ram_mmap(fd, memory, block->mr->align,
- block->flags & RAM_SHARED, block->flags & RAM_PMEM);
+ block->flags & RAM_SHARED, block->flags & RAM_PMEM,
+ offset);
if (area == MAP_FAILED) {
error_setg_errno(errp, errno,
"unable to map backing store for guest RAM");
@@ -2283,7 +2285,7 @@ static void ram_block_add(RAMBlock *new_block, Error **errp, bool shared)
#ifdef CONFIG_POSIX
RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
uint32_t ram_flags, int fd,
- Error **errp)
+ off_t offset, Error **errp)
{
RAMBlock *new_block;
Error *local_err = NULL;
@@ -2328,7 +2330,8 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
new_block->used_length = size;
new_block->max_length = size;
new_block->flags = ram_flags;
- new_block->host = file_ram_alloc(new_block, size, fd, !file_size, errp);
+ new_block->host = file_ram_alloc(new_block, size, fd, !file_size, offset,
+ errp);
if (!new_block->host) {
g_free(new_block);
return NULL;
@@ -2358,7 +2361,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
return NULL;
}
- block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, errp);
+ block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, 0, errp);
if (!block) {
if (created) {
unlink(mem_path);
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 5e59a3d8d7..1b9f489ff0 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -121,7 +121,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
Error **errp);
RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
uint32_t ram_flags, int fd,
- Error **errp);
+ off_t offset, Error **errp);
RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
MemoryRegion *mr, Error **errp);
diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
index e786266b92..4f579858bc 100644
--- a/include/qemu/mmap-alloc.h
+++ b/include/qemu/mmap-alloc.h
@@ -25,7 +25,8 @@ void *qemu_ram_mmap(int fd,
size_t size,
size_t align,
bool shared,
- bool is_pmem);
+ bool is_pmem,
+ off_t start);
void qemu_ram_munmap(int fd, void *ptr, size_t size);
diff --git a/memory.c b/memory.c
index 601b749906..f5fec476b7 100644
--- a/memory.c
+++ b/memory.c
@@ -1596,7 +1596,7 @@ void memory_region_init_ram_from_fd(MemoryRegion *mr,
mr->destructor = memory_region_destructor_ram;
mr->ram_block = qemu_ram_alloc_from_fd(size, mr,
share ? RAM_SHARED : 0,
- fd, &err);
+ fd, 0, &err);
mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
if (err) {
mr->size = int128_zero();
diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
index 27dcccd8ec..a28f7025f0 100644
--- a/util/mmap-alloc.c
+++ b/util/mmap-alloc.c
@@ -86,7 +86,8 @@ void *qemu_ram_mmap(int fd,
size_t size,
size_t align,
bool shared,
- bool is_pmem)
+ bool is_pmem,
+ off_t start)
{
int flags;
int map_sync_flags = 0;
@@ -147,7 +148,7 @@ void *qemu_ram_mmap(int fd,
offset = QEMU_ALIGN_UP((uintptr_t)guardptr, align) - (uintptr_t)guardptr;
ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE,
- flags | map_sync_flags, fd, 0);
+ flags | map_sync_flags, fd, start);
if (ptr == MAP_FAILED && map_sync_flags) {
if (errno == ENOTSUP) {
@@ -172,7 +173,7 @@ void *qemu_ram_mmap(int fd,
* we will remove these flags to handle compatibility.
*/
ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE,
- flags, fd, 0);
+ flags, fd, start);
}
if (ptr == MAP_FAILED) {
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 062236a1ab..4c6b9e90c6 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -209,7 +209,7 @@ void *qemu_memalign(size_t alignment, size_t size)
void *qemu_anon_ram_alloc(size_t size, uint64_t *alignment, bool shared)
{
size_t align = QEMU_VMALLOC_ALIGN;
- void *ptr = qemu_ram_mmap(-1, size, align, shared, false);
+ void *ptr = qemu_ram_mmap(-1, size, align, shared, false, 0);
if (ptr == MAP_FAILED) {
return NULL;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 02/36] multi-process: Refactor machine_init and exit notifiers
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-23 14:13 ` Philippe Mathieu-Daudé
2020-04-23 4:13 ` [PATCH RESEND v6 03/36] command-line: refractor parser code elena.ufimtseva
` (36 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Relocate machine_int and exit notifiers into common code
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
MAINTAINERS | 1 +
Makefile.objs | 1 +
include/sysemu/sysemu.h | 2 ++
softmmu/vl.c | 42 ----------------------
stubs/Makefile.objs | 2 ++
stubs/machine-init-add.c | 7 ++++
stubs/machine-init-done.c | 5 ++-
stubs/machine-init-remove.c | 8 +++++
util/machine-notify.c | 69 +++++++++++++++++++++++++++++++++++++
9 files changed, 92 insertions(+), 45 deletions(-)
create mode 100644 stubs/machine-init-add.c
create mode 100644 stubs/machine-init-remove.c
create mode 100644 util/machine-notify.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8cbc1fac2b..04b19ac56c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2133,6 +2133,7 @@ F: util/qemu-timer.c
F: softmmu/vl.c
F: softmmu/main.c
F: qapi/run-state.json
+F: util/machine-notify.c
Human Monitor (HMP)
M: Dr. David Alan Gilbert <dgilbert@redhat.com>
diff --git a/Makefile.objs b/Makefile.objs
index a7c967633a..bfb9271862 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -79,6 +79,7 @@ qemu-seccomp.o-libs := $(SECCOMP_LIBS)
common-obj-$(CONFIG_FDT) += device_tree.o
common-obj-y += qapi/
+common-obj-y += util/machine-notify.o
endif # CONFIG_SOFTMMU
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index ef81302e1a..2438dd7bea 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -17,11 +17,13 @@ extern bool qemu_uuid_set;
void qemu_add_exit_notifier(Notifier *notify);
void qemu_remove_exit_notifier(Notifier *notify);
+void qemu_run_exit_notifiers(void);
extern bool machine_init_done;
void qemu_add_machine_init_done_notifier(Notifier *notify);
void qemu_remove_machine_init_done_notifier(Notifier *notify);
+void qemu_run_machine_init_done_notifiers(void);
extern int autostart;
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 32c0047889..39cbb6b50d 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -172,12 +172,6 @@ int icount_align_option;
QemuUUID qemu_uuid;
bool qemu_uuid_set;
-static NotifierList exit_notifiers =
- NOTIFIER_LIST_INITIALIZER(exit_notifiers);
-
-static NotifierList machine_init_done_notifiers =
- NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
-
bool xen_allowed;
uint32_t xen_domid;
enum xen_mode xen_mode = XEN_EMULATE;
@@ -2325,21 +2319,6 @@ static MachineClass *machine_parse(const char *name, GSList *machines)
return mc;
}
-void qemu_add_exit_notifier(Notifier *notify)
-{
- notifier_list_add(&exit_notifiers, notify);
-}
-
-void qemu_remove_exit_notifier(Notifier *notify)
-{
- notifier_remove(notify);
-}
-
-static void qemu_run_exit_notifiers(void)
-{
- notifier_list_notify(&exit_notifiers, NULL);
-}
-
static const char *pid_file;
static Notifier qemu_unlink_pidfile_notifier;
@@ -2350,27 +2329,6 @@ static void qemu_unlink_pidfile(Notifier *n, void *data)
}
}
-bool machine_init_done;
-
-void qemu_add_machine_init_done_notifier(Notifier *notify)
-{
- notifier_list_add(&machine_init_done_notifiers, notify);
- if (machine_init_done) {
- notify->notify(notify, NULL);
- }
-}
-
-void qemu_remove_machine_init_done_notifier(Notifier *notify)
-{
- notifier_remove(notify);
-}
-
-static void qemu_run_machine_init_done_notifiers(void)
-{
- machine_init_done = true;
- notifier_list_notify(&machine_init_done_notifiers, NULL);
-}
-
static const QEMUOption *lookup_opt(int argc, char **argv,
const char **poptarg, int *poptind)
{
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index 45be5dc0ed..f884bb6180 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -43,4 +43,6 @@ stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
stub-obj-y += ramfb.o
stub-obj-y += fw_cfg.o
+stub-obj-y += machine-init-add.o
+stub-obj-y += machine-init-remove.o
stub-obj-$(CONFIG_SOFTMMU) += semihost.o
diff --git a/stubs/machine-init-add.c b/stubs/machine-init-add.c
new file mode 100644
index 0000000000..520dcb9801
--- /dev/null
+++ b/stubs/machine-init-add.c
@@ -0,0 +1,7 @@
+#include "qemu/osdep.h"
+#include "sysemu/sysemu.h"
+
+void qemu_add_machine_init_done_notifier(Notifier *notify)
+{
+}
+
diff --git a/stubs/machine-init-done.c b/stubs/machine-init-done.c
index cd8e81392d..a34d838f7a 100644
--- a/stubs/machine-init-done.c
+++ b/stubs/machine-init-done.c
@@ -3,6 +3,5 @@
bool machine_init_done = true;
-void qemu_add_machine_init_done_notifier(Notifier *notify)
-{
-}
+NotifierList machine_init_done_notifiers =
+ NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
diff --git a/stubs/machine-init-remove.c b/stubs/machine-init-remove.c
new file mode 100644
index 0000000000..30aee27c2d
--- /dev/null
+++ b/stubs/machine-init-remove.c
@@ -0,0 +1,8 @@
+#include "qemu/osdep.h"
+#include "sysemu/sysemu.h"
+
+void qemu_remove_machine_init_done_notifier(Notifier *notify)
+{
+}
+
+
diff --git a/util/machine-notify.c b/util/machine-notify.c
new file mode 100644
index 0000000000..718af79335
--- /dev/null
+++ b/util/machine-notify.c
@@ -0,0 +1,69 @@
+/*
+ * Machine notifiers.
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ *
+ * 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/notify.h"
+#include "sysemu/sysemu.h"
+
+static NotifierList machine_init_done_notifiers =
+ NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
+
+static NotifierList exit_notifiers =
+ NOTIFIER_LIST_INITIALIZER(exit_notifiers);
+
+bool machine_init_done;
+
+void qemu_add_machine_init_done_notifier(Notifier *notify)
+{
+ notifier_list_add(&machine_init_done_notifiers, notify);
+ if (machine_init_done) {
+ notify->notify(notify, NULL);
+ }
+}
+
+void qemu_remove_machine_init_done_notifier(Notifier *notify)
+{
+ notifier_remove(notify);
+}
+
+void qemu_run_machine_init_done_notifiers(void)
+{
+ machine_init_done = true;
+ notifier_list_notify(&machine_init_done_notifiers, NULL);
+}
+
+void qemu_add_exit_notifier(Notifier *notify)
+{
+ notifier_list_add(&exit_notifiers, notify);
+}
+
+void qemu_remove_exit_notifier(Notifier *notify)
+{
+ notifier_remove(notify);
+}
+
+void qemu_run_exit_notifiers(void)
+{
+ notifier_list_notify(&exit_notifiers, NULL);
+}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 03/36] command-line: refractor parser code
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 02/36] multi-process: Refactor machine_init and exit notifiers elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-24 12:55 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 04/36] multi-process: Refactor chardev functions out of vl.c elena.ufimtseva
` (35 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Refactor command-line parser code so that it could be used by
other processes as well.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
MAINTAINERS | 2 +
Makefile.objs | 2 +
include/qemu-parse.h | 42 ++++++++++++++++++++
qemu-parse.c | 93 ++++++++++++++++++++++++++++++++++++++++++++
softmmu/vl.c | 84 +--------------------------------------
5 files changed, 140 insertions(+), 83 deletions(-)
create mode 100644 include/qemu-parse.h
create mode 100644 qemu-parse.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 04b19ac56c..2e700e6e64 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2032,6 +2032,8 @@ F: tests/test-keyval.c
F: tests/test-qemu-opts.c
F: util/keyval.c
F: util/qemu-option.c
+F: include/qemu-parse.h
+F: qemu-parse.c
Coverity model
M: Markus Armbruster <armbru@redhat.com>
diff --git a/Makefile.objs b/Makefile.objs
index bfb9271862..f29c60c59d 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -78,6 +78,8 @@ qemu-seccomp.o-libs := $(SECCOMP_LIBS)
common-obj-$(CONFIG_FDT) += device_tree.o
+common-obj-y += qemu-parse.o
+
common-obj-y += qapi/
common-obj-y += util/machine-notify.o
diff --git a/include/qemu-parse.h b/include/qemu-parse.h
new file mode 100644
index 0000000000..156b238db6
--- /dev/null
+++ b/include/qemu-parse.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef VL_H
+#define VL_H
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+/***********************************************************/
+/* QEMU Block devices */
+
+#define HD_OPTS "media=disk"
+#define CDROM_OPTS "media=cdrom"
+#define FD_OPTS ""
+#define PFLASH_OPTS ""
+#define MTD_OPTS ""
+#define SD_OPTS ""
+
+#define HAS_ARG 0x0001
+
+typedef struct QEMUOption {
+ const char *name;
+ int flags;
+ int index;
+ uint32_t arch_mask;
+} QEMUOption;
+
+const QEMUOption *lookup_opt(int argc, char **argv, const char **poptarg,
+ int *poptind);
+
+int drive_init_func(void *opaque, QemuOpts *opts, Error **errp);
+
+int device_init_func(void *opaque, QemuOpts *opts, Error **errp);
+
+#endif /* VL_H */
+
diff --git a/qemu-parse.c b/qemu-parse.c
new file mode 100644
index 0000000000..2535374fdd
--- /dev/null
+++ b/qemu-parse.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "sysemu/blockdev.h"
+#include "sysemu/arch_init.h"
+#include "qemu/option.h"
+#include "qemu-options.h"
+#include "qapi/error.h"
+#include "qemu/error-report.h"
+#include "monitor/qdev.h"
+#include "qom/object.h"
+#include "qemu-parse.h"
+
+/***********************************************************/
+/* QEMU Block devices */
+
+static const QEMUOption qemu_options[] = {
+ { "h", 0, QEMU_OPTION_h, QEMU_ARCH_ALL },
+#define QEMU_OPTIONS_GENERATE_OPTIONS
+#include "qemu-options-wrapper.h"
+ { NULL },
+};
+
+const QEMUOption *lookup_opt(int argc, char **argv, const char **poptarg,
+ int *poptind)
+{
+ const QEMUOption *popt;
+ int optind = *poptind;
+ char *r = argv[optind];
+ const char *optarg;
+
+ loc_set_cmdline(argv, optind, 1);
+ optind++;
+ /* Treat --foo the same as -foo. */
+ if (r[1] == '-') {
+ r++;
+ }
+ popt = qemu_options;
+ for (;;) {
+ if (!popt->name) {
+ error_report("invalid option");
+ exit(1);
+ }
+ if (!strcmp(popt->name, r + 1)) {
+ break;
+ }
+ popt++;
+ }
+ if (popt->flags & HAS_ARG) {
+ if (optind >= argc) {
+ error_report("requires an argument");
+ exit(1);
+ }
+ optarg = argv[optind++];
+ loc_set_cmdline(argv, optind - 2, 2);
+ } else {
+ optarg = NULL;
+ }
+
+ *poptarg = optarg;
+ *poptind = optind;
+
+ return popt;
+}
+
+int drive_init_func(void *opaque, QemuOpts *opts, Error **errp)
+{
+ BlockInterfaceType *block_default_type = opaque;
+
+ return drive_new(opts, *block_default_type, errp) == NULL;
+}
+
+int device_init_func(void *opaque, QemuOpts *opts, Error **errp)
+{
+ DeviceState *dev;
+
+ dev = qdev_device_add(opts, errp);
+ if (!dev && *errp) {
+ error_report_err(*errp);
+ return -1;
+ } else if (dev) {
+ object_unref(OBJECT(dev));
+ }
+ return 0;
+}
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 39cbb6b50d..d1b32a33a2 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -36,6 +36,7 @@
#include "sysemu/runstate.h"
#include "sysemu/seccomp.h"
#include "sysemu/tcg.h"
+#include "qemu-parse.h"
#include "qemu/error-report.h"
#include "qemu/sockets.h"
@@ -969,20 +970,6 @@ static int cleanup_add_fd(void *opaque, QemuOpts *opts, Error **errp)
/***********************************************************/
/* QEMU Block devices */
-#define HD_OPTS "media=disk"
-#define CDROM_OPTS "media=cdrom"
-#define FD_OPTS ""
-#define PFLASH_OPTS ""
-#define MTD_OPTS ""
-#define SD_OPTS ""
-
-static int drive_init_func(void *opaque, QemuOpts *opts, Error **errp)
-{
- BlockInterfaceType *block_default_type = opaque;
-
- return drive_new(opts, *block_default_type, errp) == NULL;
-}
-
static int drive_enable_snapshot(void *opaque, QemuOpts *opts, Error **errp)
{
if (qemu_opt_get(opts, "snapshot") == NULL) {
@@ -1690,21 +1677,6 @@ static void help(int exitcode)
exit(exitcode);
}
-#define HAS_ARG 0x0001
-
-typedef struct QEMUOption {
- const char *name;
- int flags;
- int index;
- uint32_t arch_mask;
-} QEMUOption;
-
-static const QEMUOption qemu_options[] = {
- { "h", 0, QEMU_OPTION_h, QEMU_ARCH_ALL },
-#define QEMU_OPTIONS_GENERATE_OPTIONS
-#include "qemu-options-wrapper.h"
- { NULL },
-};
typedef struct VGAInterfaceInfo {
const char *opt_name; /* option name */
@@ -2066,20 +2038,6 @@ static int device_help_func(void *opaque, QemuOpts *opts, Error **errp)
return qdev_device_help(opts);
}
-static int device_init_func(void *opaque, QemuOpts *opts, Error **errp)
-{
- DeviceState *dev;
-
- dev = qdev_device_add(opts, errp);
- if (!dev && *errp) {
- error_report_err(*errp);
- return -1;
- } else if (dev) {
- object_unref(OBJECT(dev));
- }
- return 0;
-}
-
static int chardev_init_func(void *opaque, QemuOpts *opts, Error **errp)
{
Error *local_err = NULL;
@@ -2329,46 +2287,6 @@ static void qemu_unlink_pidfile(Notifier *n, void *data)
}
}
-static const QEMUOption *lookup_opt(int argc, char **argv,
- const char **poptarg, int *poptind)
-{
- const QEMUOption *popt;
- int optind = *poptind;
- char *r = argv[optind];
- const char *optarg;
-
- loc_set_cmdline(argv, optind, 1);
- optind++;
- /* Treat --foo the same as -foo. */
- if (r[1] == '-')
- r++;
- popt = qemu_options;
- for(;;) {
- if (!popt->name) {
- error_report("invalid option");
- exit(1);
- }
- if (!strcmp(popt->name, r + 1))
- break;
- popt++;
- }
- if (popt->flags & HAS_ARG) {
- if (optind >= argc) {
- error_report("requires an argument");
- exit(1);
- }
- optarg = argv[optind++];
- loc_set_cmdline(argv, optind - 2, 2);
- } else {
- optarg = NULL;
- }
-
- *poptarg = optarg;
- *poptind = optind;
-
- return popt;
-}
-
static MachineClass *select_machine(void)
{
GSList *machines = object_class_get_list(TYPE_MACHINE, false);
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 04/36] multi-process: Refactor chardev functions out of vl.c
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (2 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 03/36] command-line: refractor parser code elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 05/36] multi-process: Refactor monitor " elena.ufimtseva
` (34 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Some of the initialization helper functions w.r.t chardev
in vl.c are also used by the remote process. Therefore, these functions
are refactored into shared files that both QEMU & remote process
could use.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
chardev/char.c | 14 ++++++++++++++
include/chardev/char.h | 2 ++
softmmu/vl.c | 14 --------------
3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/chardev/char.c b/chardev/char.c
index e77564060d..47dcf93da7 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -1196,3 +1196,17 @@ static void register_types(void)
}
type_init(register_types);
+
+int chardev_init_func(void *opaque, QemuOpts *opts, Error **errp)
+{
+ Error *local_err = NULL;
+
+ if (!qemu_chr_new_from_opts(opts, NULL, &local_err)) {
+ if (local_err) {
+ error_propagate(errp, local_err);
+ return -1;
+ }
+ exit(0);
+ }
+ return 0;
+}
diff --git a/include/chardev/char.h b/include/chardev/char.h
index 00589a6025..0804e78f7a 100644
--- a/include/chardev/char.h
+++ b/include/chardev/char.h
@@ -290,4 +290,6 @@ GSource *qemu_chr_timeout_add_ms(Chardev *chr, guint ms,
/* console.c */
void qemu_chr_parse_vc(QemuOpts *opts, ChardevBackend *backend, Error **errp);
+int chardev_init_func(void *opaque, QemuOpts *opts, Error **errp);
+
#endif
diff --git a/softmmu/vl.c b/softmmu/vl.c
index d1b32a33a2..6e35f3787d 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2038,20 +2038,6 @@ static int device_help_func(void *opaque, QemuOpts *opts, Error **errp)
return qdev_device_help(opts);
}
-static int chardev_init_func(void *opaque, QemuOpts *opts, Error **errp)
-{
- Error *local_err = NULL;
-
- if (!qemu_chr_new_from_opts(opts, NULL, &local_err)) {
- if (local_err) {
- error_propagate(errp, local_err);
- return -1;
- }
- exit(0);
- }
- return 0;
-}
-
#ifdef CONFIG_VIRTFS
static int fsdev_init_func(void *opaque, QemuOpts *opts, Error **errp)
{
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 05/36] multi-process: Refactor monitor functions out of vl.c
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (3 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 04/36] multi-process: Refactor chardev functions out of vl.c elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-24 13:02 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 06/36] monitor: destaticize HMP commands elena.ufimtseva
` (33 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Some of the initialization helper functions w.r.t monitor
in vl.c are also used by the remote process. Therefore, these functions
are refactored into shared files that both QEMU & remote process
could use.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
include/monitor/monitor.h | 3 +++
monitor/monitor.c | 37 +++++++++++++++++++++++++++++++++++++
softmmu/vl.c | 35 -----------------------------------
3 files changed, 40 insertions(+), 35 deletions(-)
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 1018d754a6..3803e904f2 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -48,4 +48,7 @@ int monitor_fdset_dup_fd_add(int64_t fdset_id, int dup_fd);
void monitor_fdset_dup_fd_remove(int dup_fd);
int64_t monitor_fdset_dup_fd_find(int dup_fd);
+int mon_init_func(void *opaque, QemuOpts *opts, Error **errp);
+void monitor_parse(const char *optarg, const char *mode, bool pretty);
+
#endif /* MONITOR_H */
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 125494410a..88423b38b6 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -35,6 +35,8 @@
#include "sysemu/qtest.h"
#include "sysemu/sysemu.h"
#include "trace.h"
+#include "qemu/cutils.h"
+#include "qemu/config-file.h"
/*
* To prevent flooding clients, events can be throttled. The
@@ -611,6 +613,41 @@ void monitor_init_globals_core(void)
NULL);
}
+int mon_init_func(void *opaque, QemuOpts *opts, Error **errp)
+{
+ return monitor_init_opts(opts, errp);
+}
+
+void monitor_parse(const char *optarg, const char *mode, bool pretty)
+{
+ static int monitor_device_index;
+ QemuOpts *opts;
+ const char *p;
+ char label[32];
+
+ if (strstart(optarg, "chardev:", &p)) {
+ snprintf(label, sizeof(label), "%s", p);
+ } else {
+ snprintf(label, sizeof(label), "compat_monitor%d",
+ monitor_device_index);
+ opts = qemu_chr_parse_compat(label, optarg, true);
+ if (!opts) {
+ error_report("parse error: %s", optarg);
+ exit(1);
+ }
+ }
+
+ opts = qemu_opts_create(qemu_find_opts("mon"), label, 1, &error_fatal);
+ qemu_opt_set(opts, "mode", mode, &error_abort);
+ qemu_opt_set(opts, "chardev", label, &error_abort);
+ if (!strcmp(mode, "control")) {
+ qemu_opt_set_bool(opts, "pretty", pretty, &error_abort);
+ } else {
+ assert(pretty == false);
+ }
+ monitor_device_index++;
+}
+
int monitor_init(MonitorOptions *opts, bool allow_hmp, Error **errp)
{
Chardev *chr;
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 6e35f3787d..abc746c1b5 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2045,41 +2045,6 @@ static int fsdev_init_func(void *opaque, QemuOpts *opts, Error **errp)
}
#endif
-static int mon_init_func(void *opaque, QemuOpts *opts, Error **errp)
-{
- return monitor_init_opts(opts, errp);
-}
-
-static void monitor_parse(const char *optarg, const char *mode, bool pretty)
-{
- static int monitor_device_index = 0;
- QemuOpts *opts;
- const char *p;
- char label[32];
-
- if (strstart(optarg, "chardev:", &p)) {
- snprintf(label, sizeof(label), "%s", p);
- } else {
- snprintf(label, sizeof(label), "compat_monitor%d",
- monitor_device_index);
- opts = qemu_chr_parse_compat(label, optarg, true);
- if (!opts) {
- error_report("parse error: %s", optarg);
- exit(1);
- }
- }
-
- opts = qemu_opts_create(qemu_find_opts("mon"), label, 1, &error_fatal);
- qemu_opt_set(opts, "mode", mode, &error_abort);
- qemu_opt_set(opts, "chardev", label, &error_abort);
- if (!strcmp(mode, "control")) {
- qemu_opt_set_bool(opts, "pretty", pretty, &error_abort);
- } else {
- assert(pretty == false);
- }
- monitor_device_index++;
-}
-
struct device_config {
enum {
DEV_USB, /* -usbdevice */
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 06/36] monitor: destaticize HMP commands
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (4 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 05/36] multi-process: Refactor monitor " elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-23 14:14 ` Philippe Mathieu-Daudé
2020-04-23 4:13 ` [PATCH RESEND v6 07/36] multi-process: add a command line option for debug file elena.ufimtseva
` (32 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
hmp-commands.hx | 4 +-
monitor/misc.c | 76 +++++++++++++++++++-------------------
monitor/monitor-internal.h | 38 +++++++++++++++++++
3 files changed, 78 insertions(+), 40 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 7f0f3974ad..02cae25c24 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -11,7 +11,7 @@ HXCOMM HXCOMM can be used for comments, discarded from both rST and C.
.args_type = "name:S?",
.params = "[cmd]",
.help = "show the help",
- .cmd = do_help_cmd,
+ .cmd = hmp_do_help_cmd,
.flags = "p",
},
@@ -555,7 +555,7 @@ ERST
.args_type = "fmt:/,val:l",
.params = "/fmt expr",
.help = "print expression value (use $reg for CPU register access)",
- .cmd = do_print,
+ .cmd = hmp_do_print,
},
SRST
diff --git a/monitor/misc.c b/monitor/misc.c
index 6c45fa490f..c0eee6f4ab 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -178,12 +178,12 @@ int hmp_compare_cmd(const char *name, const char *list)
return 0;
}
-static void do_help_cmd(Monitor *mon, const QDict *qdict)
+void hmp_do_help_cmd(Monitor *mon, const QDict *qdict)
{
help_cmd(mon, qdict_get_try_str(qdict, "name"));
}
-static void hmp_trace_event(Monitor *mon, const QDict *qdict)
+void hmp_trace_event(Monitor *mon, const QDict *qdict)
{
const char *tp_name = qdict_get_str(qdict, "name");
bool new_state = qdict_get_bool(qdict, "option");
@@ -227,7 +227,7 @@ static void hmp_trace_file(Monitor *mon, const QDict *qdict)
}
#endif
-static void hmp_info_help(Monitor *mon, const QDict *qdict)
+void hmp_info_help(Monitor *mon, const QDict *qdict)
{
help_cmd(mon, "info");
}
@@ -315,7 +315,7 @@ int monitor_get_cpu_index(void)
return cs ? cs->cpu_index : UNASSIGNED_CPU_INDEX;
}
-static void hmp_info_registers(Monitor *mon, const QDict *qdict)
+void hmp_info_registers(Monitor *mon, const QDict *qdict)
{
bool all_cpus = qdict_get_try_bool(qdict, "cpustate_all", false);
CPUState *cs;
@@ -338,7 +338,7 @@ static void hmp_info_registers(Monitor *mon, const QDict *qdict)
}
#ifdef CONFIG_TCG
-static void hmp_info_jit(Monitor *mon, const QDict *qdict)
+void hmp_info_jit(Monitor *mon, const QDict *qdict)
{
if (!tcg_enabled()) {
error_report("JIT information is only available with accel=tcg");
@@ -349,13 +349,13 @@ static void hmp_info_jit(Monitor *mon, const QDict *qdict)
dump_drift_info();
}
-static void hmp_info_opcount(Monitor *mon, const QDict *qdict)
+void hmp_info_opcount(Monitor *mon, const QDict *qdict)
{
dump_opcount_info();
}
#endif
-static void hmp_info_sync_profile(Monitor *mon, const QDict *qdict)
+void hmp_info_sync_profile(Monitor *mon, const QDict *qdict)
{
int64_t max = qdict_get_try_int(qdict, "max", 10);
bool mean = qdict_get_try_bool(qdict, "mean", false);
@@ -366,7 +366,7 @@ static void hmp_info_sync_profile(Monitor *mon, const QDict *qdict)
qsp_report(max, sort_by, coalesce);
}
-static void hmp_info_history(Monitor *mon, const QDict *qdict)
+void hmp_info_history(Monitor *mon, const QDict *qdict)
{
MonitorHMP *hmp_mon = container_of(mon, MonitorHMP, common);
int i;
@@ -386,7 +386,7 @@ static void hmp_info_history(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_info_cpustats(Monitor *mon, const QDict *qdict)
+void hmp_info_cpustats(Monitor *mon, const QDict *qdict)
{
CPUState *cs = mon_get_cpu();
@@ -397,7 +397,7 @@ static void hmp_info_cpustats(Monitor *mon, const QDict *qdict)
cpu_dump_statistics(cs, 0);
}
-static void hmp_info_trace_events(Monitor *mon, const QDict *qdict)
+void hmp_info_trace_events(Monitor *mon, const QDict *qdict)
{
const char *name = qdict_get_try_str(qdict, "name");
bool has_vcpu = qdict_haskey(qdict, "vcpu");
@@ -457,7 +457,7 @@ void qmp_client_migrate_info(const char *protocol, const char *hostname,
error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "protocol", "spice");
}
-static void hmp_logfile(Monitor *mon, const QDict *qdict)
+void hmp_logfile(Monitor *mon, const QDict *qdict)
{
Error *err = NULL;
@@ -467,7 +467,7 @@ static void hmp_logfile(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_log(Monitor *mon, const QDict *qdict)
+void hmp_log(Monitor *mon, const QDict *qdict)
{
int mask;
const char *items = qdict_get_str(qdict, "items");
@@ -484,7 +484,7 @@ static void hmp_log(Monitor *mon, const QDict *qdict)
qemu_set_log(mask);
}
-static void hmp_singlestep(Monitor *mon, const QDict *qdict)
+void hmp_singlestep(Monitor *mon, const QDict *qdict)
{
const char *option = qdict_get_try_str(qdict, "option");
if (!option || !strcmp(option, "on")) {
@@ -496,7 +496,7 @@ static void hmp_singlestep(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_gdbserver(Monitor *mon, const QDict *qdict)
+void hmp_gdbserver(Monitor *mon, const QDict *qdict)
{
const char *device = qdict_get_try_str(qdict, "device");
if (!device)
@@ -512,7 +512,7 @@ static void hmp_gdbserver(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_watchdog_action(Monitor *mon, const QDict *qdict)
+void hmp_watchdog_action(Monitor *mon, const QDict *qdict)
{
const char *action = qdict_get_str(qdict, "action");
if (select_watchdog_action(action) == -1) {
@@ -654,7 +654,7 @@ static void memory_dump(Monitor *mon, int count, int format, int wsize,
}
}
-static void hmp_memory_dump(Monitor *mon, const QDict *qdict)
+void hmp_memory_dump(Monitor *mon, const QDict *qdict)
{
int count = qdict_get_int(qdict, "count");
int format = qdict_get_int(qdict, "format");
@@ -664,7 +664,7 @@ static void hmp_memory_dump(Monitor *mon, const QDict *qdict)
memory_dump(mon, count, format, size, addr, 0);
}
-static void hmp_physical_memory_dump(Monitor *mon, const QDict *qdict)
+void hmp_physical_memory_dump(Monitor *mon, const QDict *qdict)
{
int count = qdict_get_int(qdict, "count");
int format = qdict_get_int(qdict, "format");
@@ -694,7 +694,7 @@ static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
return qemu_map_ram_ptr(mrs.mr->ram_block, mrs.offset_within_region);
}
-static void hmp_gpa2hva(Monitor *mon, const QDict *qdict)
+void hmp_gpa2hva(Monitor *mon, const QDict *qdict)
{
hwaddr addr = qdict_get_int(qdict, "addr");
Error *local_err = NULL;
@@ -714,7 +714,7 @@ static void hmp_gpa2hva(Monitor *mon, const QDict *qdict)
memory_region_unref(mr);
}
-static void hmp_gva2gpa(Monitor *mon, const QDict *qdict)
+void hmp_gva2gpa(Monitor *mon, const QDict *qdict)
{
target_ulong addr = qdict_get_int(qdict, "addr");
MemTxAttrs attrs;
@@ -769,7 +769,7 @@ out:
return ret;
}
-static void hmp_gpa2hpa(Monitor *mon, const QDict *qdict)
+void hmp_gpa2hpa(Monitor *mon, const QDict *qdict)
{
hwaddr addr = qdict_get_int(qdict, "addr");
Error *local_err = NULL;
@@ -796,7 +796,7 @@ static void hmp_gpa2hpa(Monitor *mon, const QDict *qdict)
}
#endif
-static void do_print(Monitor *mon, const QDict *qdict)
+void hmp_do_print(Monitor *mon, const QDict *qdict)
{
int format = qdict_get_int(qdict, "format");
hwaddr val = qdict_get_int(qdict, "val");
@@ -822,7 +822,7 @@ static void do_print(Monitor *mon, const QDict *qdict)
monitor_printf(mon, "\n");
}
-static void hmp_sum(Monitor *mon, const QDict *qdict)
+void hmp_sum(Monitor *mon, const QDict *qdict)
{
uint32_t addr;
uint16_t sum;
@@ -842,7 +842,7 @@ static void hmp_sum(Monitor *mon, const QDict *qdict)
static int mouse_button_state;
-static void hmp_mouse_move(Monitor *mon, const QDict *qdict)
+void hmp_mouse_move(Monitor *mon, const QDict *qdict)
{
int dx, dy, dz, button;
const char *dx_str = qdict_get_str(qdict, "dx_str");
@@ -866,7 +866,7 @@ static void hmp_mouse_move(Monitor *mon, const QDict *qdict)
qemu_input_event_sync();
}
-static void hmp_mouse_button(Monitor *mon, const QDict *qdict)
+void hmp_mouse_button(Monitor *mon, const QDict *qdict)
{
static uint32_t bmap[INPUT_BUTTON__MAX] = {
[INPUT_BUTTON_LEFT] = MOUSE_EVENT_LBUTTON,
@@ -883,7 +883,7 @@ static void hmp_mouse_button(Monitor *mon, const QDict *qdict)
mouse_button_state = button_state;
}
-static void hmp_ioport_read(Monitor *mon, const QDict *qdict)
+void hmp_ioport_read(Monitor *mon, const QDict *qdict)
{
int size = qdict_get_int(qdict, "size");
int addr = qdict_get_int(qdict, "addr");
@@ -917,7 +917,7 @@ static void hmp_ioport_read(Monitor *mon, const QDict *qdict)
suffix, addr, size * 2, val);
}
-static void hmp_ioport_write(Monitor *mon, const QDict *qdict)
+void hmp_ioport_write(Monitor *mon, const QDict *qdict)
{
int size = qdict_get_int(qdict, "size");
int addr = qdict_get_int(qdict, "addr");
@@ -939,7 +939,7 @@ static void hmp_ioport_write(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_boot_set(Monitor *mon, const QDict *qdict)
+void hmp_boot_set(Monitor *mon, const QDict *qdict)
{
Error *local_err = NULL;
const char *bootdevice = qdict_get_str(qdict, "bootdevice");
@@ -952,7 +952,7 @@ static void hmp_boot_set(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_info_mtree(Monitor *mon, const QDict *qdict)
+void hmp_info_mtree(Monitor *mon, const QDict *qdict)
{
bool flatview = qdict_get_try_bool(qdict, "flatview", false);
bool dispatch_tree = qdict_get_try_bool(qdict, "dispatch_tree", false);
@@ -965,7 +965,7 @@ static void hmp_info_mtree(Monitor *mon, const QDict *qdict)
int64_t dev_time;
-static void hmp_info_profile(Monitor *mon, const QDict *qdict)
+void hmp_info_profile(Monitor *mon, const QDict *qdict)
{
static int64_t last_cpu_exec_time;
int64_t cpu_exec_time;
@@ -982,7 +982,7 @@ static void hmp_info_profile(Monitor *mon, const QDict *qdict)
dev_time = 0;
}
#else
-static void hmp_info_profile(Monitor *mon, const QDict *qdict)
+void hmp_info_profile(Monitor *mon, const QDict *qdict)
{
monitor_printf(mon, "Internal profiler not compiled\n");
}
@@ -991,7 +991,7 @@ static void hmp_info_profile(Monitor *mon, const QDict *qdict)
/* Capture support */
static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
-static void hmp_info_capture(Monitor *mon, const QDict *qdict)
+void hmp_info_capture(Monitor *mon, const QDict *qdict)
{
int i;
CaptureState *s;
@@ -1002,7 +1002,7 @@ static void hmp_info_capture(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_stopcapture(Monitor *mon, const QDict *qdict)
+void hmp_stopcapture(Monitor *mon, const QDict *qdict)
{
int i;
int n = qdict_get_int(qdict, "n");
@@ -1018,7 +1018,7 @@ static void hmp_stopcapture(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_wavcapture(Monitor *mon, const QDict *qdict)
+void hmp_wavcapture(Monitor *mon, const QDict *qdict)
{
const char *path = qdict_get_str(qdict, "path");
int freq = qdict_get_try_int(qdict, "freq", 44100);
@@ -1071,7 +1071,7 @@ static void hmp_warn_acl(void)
warn_acl = true;
}
-static void hmp_acl_show(Monitor *mon, const QDict *qdict)
+void hmp_acl_show(Monitor *mon, const QDict *qdict)
{
const char *aclname = qdict_get_str(qdict, "aclname");
QAuthZList *auth = find_auth(mon, aclname);
@@ -1098,7 +1098,7 @@ static void hmp_acl_show(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_acl_reset(Monitor *mon, const QDict *qdict)
+void hmp_acl_reset(Monitor *mon, const QDict *qdict)
{
const char *aclname = qdict_get_str(qdict, "aclname");
QAuthZList *auth = find_auth(mon, aclname);
@@ -1115,7 +1115,7 @@ static void hmp_acl_reset(Monitor *mon, const QDict *qdict)
monitor_printf(mon, "acl: removed all rules\n");
}
-static void hmp_acl_policy(Monitor *mon, const QDict *qdict)
+void hmp_acl_policy(Monitor *mon, const QDict *qdict)
{
const char *aclname = qdict_get_str(qdict, "aclname");
const char *policy = qdict_get_str(qdict, "policy");
@@ -1156,7 +1156,7 @@ static QAuthZListFormat hmp_acl_get_format(const char *match)
}
}
-static void hmp_acl_add(Monitor *mon, const QDict *qdict)
+void hmp_acl_add(Monitor *mon, const QDict *qdict)
{
const char *aclname = qdict_get_str(qdict, "aclname");
const char *match = qdict_get_str(qdict, "match");
@@ -1209,7 +1209,7 @@ static void hmp_acl_add(Monitor *mon, const QDict *qdict)
}
}
-static void hmp_acl_remove(Monitor *mon, const QDict *qdict)
+void hmp_acl_remove(Monitor *mon, const QDict *qdict)
{
const char *aclname = qdict_get_str(qdict, "aclname");
const char *match = qdict_get_str(qdict, "match");
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index 8f60ccc70a..bc8c9fa16b 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -183,4 +183,42 @@ int hmp_compare_cmd(const char *name, const char *list);
void qmp_query_qmp_schema(QDict *qdict, QObject **ret_data,
Error **errp);
+void hmp_do_help_cmd(Monitor *mon, const QDict *qdict);
+void hmp_trace_event(Monitor *mon, const QDict *qdict);
+void hmp_info_help(Monitor *mon, const QDict *qdict);
+void hmp_info_registers(Monitor *mon, const QDict *qdict);
+void hmp_info_jit(Monitor *mon, const QDict *qdict);
+void hmp_info_opcount(Monitor *mon, const QDict *qdict);
+void hmp_info_sync_profile(Monitor *mon, const QDict *qdict);
+void hmp_info_history(Monitor *mon, const QDict *qdict);
+void hmp_info_cpustats(Monitor *mon, const QDict *qdict);
+void hmp_info_trace_events(Monitor *mon, const QDict *qdict);
+void hmp_logfile(Monitor *mon, const QDict *qdict);
+void hmp_log(Monitor *mon, const QDict *qdict);
+void hmp_singlestep(Monitor *mon, const QDict *qdict);
+void hmp_gdbserver(Monitor *mon, const QDict *qdict);
+void hmp_watchdog_action(Monitor *mon, const QDict *qdict);
+void hmp_memory_dump(Monitor *mon, const QDict *qdict);
+void hmp_physical_memory_dump(Monitor *mon, const QDict *qdict);
+void hmp_gpa2hva(Monitor *mon, const QDict *qdict);
+void hmp_gva2gpa(Monitor *mon, const QDict *qdict);
+void hmp_gpa2hpa(Monitor *mon, const QDict *qdict);
+void hmp_do_print(Monitor *mon, const QDict *qdict);
+void hmp_sum(Monitor *mon, const QDict *qdict);
+void hmp_mouse_move(Monitor *mon, const QDict *qdict);
+void hmp_mouse_button(Monitor *mon, const QDict *qdict);
+void hmp_ioport_read(Monitor *mon, const QDict *qdict);
+void hmp_ioport_write(Monitor *mon, const QDict *qdict);
+void hmp_boot_set(Monitor *mon, const QDict *qdict);
+void hmp_info_mtree(Monitor *mon, const QDict *qdict);
+void hmp_info_profile(Monitor *mon, const QDict *qdict);
+void hmp_info_capture(Monitor *mon, const QDict *qdict);
+void hmp_stopcapture(Monitor *mon, const QDict *qdict);
+void hmp_wavcapture(Monitor *mon, const QDict *qdict);
+void hmp_acl_show(Monitor *mon, const QDict *qdict);
+void hmp_acl_reset(Monitor *mon, const QDict *qdict);
+void hmp_acl_policy(Monitor *mon, const QDict *qdict);
+void hmp_acl_add(Monitor *mon, const QDict *qdict);
+void hmp_acl_remove(Monitor *mon, const QDict *qdict);
+
#endif
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 07/36] multi-process: add a command line option for debug file
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (5 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 06/36] monitor: destaticize HMP commands elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process elena.ufimtseva
` (31 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Can be used with -d rdebug command options when starting qemu.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
---
include/qemu/log.h | 1 +
util/log.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/qemu/log.h b/include/qemu/log.h
index f4724f7330..a039ddb61a 100644
--- a/include/qemu/log.h
+++ b/include/qemu/log.h
@@ -64,6 +64,7 @@ static inline bool qemu_log_separate(void)
#define CPU_LOG_PLUGIN (1 << 18)
/* LOG_STRACE is used for user-mode strace logging. */
#define LOG_STRACE (1 << 19)
+#define LOG_REMOTE_DEBUG (1 << 20)
/* Lock output for a series of related logs. Since this is not needed
* for a single qemu_log / qemu_log_mask / qemu_log_mask_and_addr, we
diff --git a/util/log.c b/util/log.c
index 2da6cb31dc..1f90e70cdd 100644
--- a/util/log.c
+++ b/util/log.c
@@ -334,6 +334,8 @@ const QEMULogItem qemu_log_items[] = {
#endif
{ LOG_STRACE, "strace",
"log every user-mode syscall, its input, and its result" },
+ { LOG_REMOTE_DEBUG, "rdebug",
+ "log remote debug" },
{ 0, NULL, NULL },
};
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (6 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 07/36] multi-process: add a command line option for debug file elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-24 13:12 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 09/36] multi-process: Add config option for multi-process QEMU elena.ufimtseva
` (30 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Add stub functions that are needed during compile time but not in
runtime.
To avoid duplicate symbol while linking for monitor_get_fd, put in
a separate file.
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 3 ++
accel/stubs/kvm-stub.c | 5 +++
accel/stubs/tcg-stub.c | 98 ++++++++++++++++++++++++++++++++++++++++++
stubs/Makefile.objs | 1 +
stubs/audio.c | 12 ++++++
stubs/get-fd.c | 10 +++++
stubs/monitor.c | 53 +++++++++++++++++++++--
stubs/net-stub.c | 31 +++++++++++++
stubs/replay.c | 14 ++++++
stubs/vl-stub.c | 79 ++++++++++++++++++++++++++++++++++
stubs/vmstate.c | 19 ++++++++
stubs/xen-mapcache.c | 22 ++++++++++
12 files changed, 344 insertions(+), 3 deletions(-)
create mode 100644 stubs/audio.c
create mode 100644 stubs/get-fd.c
create mode 100644 stubs/net-stub.c
create mode 100644 stubs/vl-stub.c
create mode 100644 stubs/xen-mapcache.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 2e700e6e64..c5fba124e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -450,6 +450,7 @@ F: hw/pci-host/xen_igd_pt.c
F: include/hw/block/dataplane/xen*
F: include/hw/xen/
F: include/sysemu/xen-mapcache.h
+F: stubs/xen-mapcache.c
Guest CPU Cores (HAXM)
---------------------
@@ -1927,6 +1928,7 @@ F: include/hw/audio/
F: tests/qtest/ac97-test.c
F: tests/qtest/es1370-test.c
F: tests/qtest/intel-hda-test.c
+F: stubs/audio.c
Block layer core
M: Kevin Wolf <kwolf@redhat.com>
@@ -2159,6 +2161,7 @@ F: include/net/
F: qemu-bridge-helper.c
T: git https://github.com/jasowang/qemu.git net
F: qapi/net.json
+F: stubs/net-stub.c
Netmap network backend
M: Luigi Rizzo <rizzo@iet.unipi.it>
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 82f118d2df..baa6b38da4 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -31,6 +31,7 @@ bool kvm_allowed;
bool kvm_readonly_mem_allowed;
bool kvm_ioeventfd_any_length_allowed;
bool kvm_msi_use_devid;
+bool kvm_halt_in_kernel_allowed;
int kvm_destroy_vcpu(CPUState *cpu)
{
@@ -58,6 +59,10 @@ void kvm_cpu_synchronize_post_init(CPUState *cpu)
{
}
+void kvm_cpu_synchronize_pre_loadvm(CPUState *cpu)
+{
+}
+
int kvm_cpu_exec(CPUState *cpu)
{
abort();
diff --git a/accel/stubs/tcg-stub.c b/accel/stubs/tcg-stub.c
index 677191a69c..2e4e8741fb 100644
--- a/accel/stubs/tcg-stub.c
+++ b/accel/stubs/tcg-stub.c
@@ -11,14 +11,112 @@
*/
#include "qemu/osdep.h"
+#include "qemu-common.h"
#include "cpu.h"
#include "tcg/tcg.h"
#include "exec/exec-all.h"
+#include "translate-all.h"
+#include "exec/ram_addr.h"
+
+bool parallel_cpus;
void tb_flush(CPUState *cpu)
{
}
+#ifdef CONFIG_MPQEMU
+void tb_check_watchpoint(CPUState *cpu, uintptr_t retaddr)
+{
+}
+
+void tb_invalidate_phys_range(ram_addr_t start, ram_addr_t end)
+{
+}
+
+void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end)
+{
+}
+
+void tb_invalidate_phys_page_fast(struct page_collection *pages,
+ tb_page_addr_t start, int len,
+ uintptr_t retaddr)
+{
+}
+
+void tlb_init(CPUState *cpu)
+{
+}
+
void tlb_set_dirty(CPUState *cpu, target_ulong vaddr)
{
}
+
+void tlb_flush(CPUState *cpu)
+{
+}
+
+void tlb_flush_page(CPUState *cpu, target_ulong addr)
+{
+}
+
+void tlb_reset_dirty(CPUState *cpu, ram_addr_t start1, ram_addr_t length)
+{
+}
+
+void tcg_region_init(void)
+{
+}
+
+void tcg_register_thread(void)
+{
+}
+
+void tcg_flush_softmmu_tlb(CPUState *cs)
+{
+}
+
+void cpu_loop_exit_noexc(CPUState *cpu)
+{
+ cpu->exception_index = -1;
+ cpu_loop_exit(cpu);
+}
+
+void cpu_loop_exit(CPUState *cpu)
+{
+ cpu->can_do_io = 1;
+ siglongjmp(cpu->jmp_env, 1);
+}
+
+void cpu_reloading_memory_map(void)
+{
+}
+
+int cpu_exec(CPUState *cpu)
+{
+ return 0;
+}
+
+void cpu_exec_step_atomic(CPUState *cpu)
+{
+}
+
+bool cpu_restore_state(CPUState *cpu, uintptr_t host_pc, bool will_exit)
+{
+ return false;
+}
+
+void cpu_loop_exit_restore(CPUState *cpu, uintptr_t pc)
+{
+ cpu_loop_exit(cpu);
+}
+
+struct page_collection *
+page_collection_lock(tb_page_addr_t start, tb_page_addr_t end)
+{
+ return NULL;
+}
+
+void page_collection_unlock(struct page_collection *set)
+{
+}
+#endif
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index f884bb6180..f74c7e927b 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -20,6 +20,7 @@ stub-obj-y += migr-blocker.o
stub-obj-y += change-state-handler.o
stub-obj-y += monitor.o
stub-obj-y += monitor-core.o
+stub-obj-y += get-fd.o
stub-obj-y += notify-event.o
stub-obj-y += qtest.o
stub-obj-y += replay.o
diff --git a/stubs/audio.c b/stubs/audio.c
new file mode 100644
index 0000000000..8ae3b0f568
--- /dev/null
+++ b/stubs/audio.c
@@ -0,0 +1,12 @@
+#include "qemu/osdep.h"
+#include "audio/audio.h"
+
+AudioState *audio_state_by_name(const char *name)
+{
+ return NULL;
+}
+
+const char *audio_get_id(QEMUSoundCard *card)
+{
+ return NULL;
+}
diff --git a/stubs/get-fd.c b/stubs/get-fd.c
new file mode 100644
index 0000000000..6800dbe6d4
--- /dev/null
+++ b/stubs/get-fd.c
@@ -0,0 +1,10 @@
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "monitor/monitor.h"
+#include "../monitor/monitor-internal.h"
+
+int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
+{
+ error_setg(errp, "only QEMU supports file descriptor passing");
+ return -1;
+}
diff --git a/stubs/monitor.c b/stubs/monitor.c
index 20786ac4ff..4613bc23e0 100644
--- a/stubs/monitor.c
+++ b/stubs/monitor.c
@@ -2,11 +2,27 @@
#include "qapi/error.h"
#include "monitor/monitor.h"
#include "../monitor/monitor-internal.h"
+#include "qapi/qapi-types-misc.h"
+#include "qapi/qapi-commands-misc.h"
+#include "qapi/qapi-types-qom.h"
+#include "qapi/qapi-commands-qdev.h"
+#include "hw/qdev-core.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/runstate.h"
+#include "monitor/hmp.h"
-int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
+#pragma weak hmp_handle_error
+#pragma weak cur_mon
+#pragma weak monitor_vprintf
+#pragma weak monitor_printf
+#pragma weak monitor_cur_is_qmp
+#pragma weak qmp_device_list_properties
+
+__thread Monitor *cur_mon;
+
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
{
- error_setg(errp, "only QEMU supports file descriptor passing");
- return -1;
+ abort();
}
void monitor_init_hmp(Chardev *chr, bool use_readline, Error **errp)
@@ -16,3 +32,34 @@ void monitor_init_hmp(Chardev *chr, bool use_readline, Error **errp)
void monitor_fdsets_cleanup(void)
{
}
+
+int monitor_get_cpu_index(void)
+{
+ return -ENOSYS;
+}
+int monitor_printf(Monitor *mon, const char *fmt, ...)
+{
+ return -ENOSYS;
+}
+
+bool monitor_cur_is_qmp(void)
+{
+ return false;
+}
+
+ObjectPropertyInfoList *qmp_device_list_properties(const char *typename,
+ Error **errp)
+{
+ return NULL;
+}
+
+VMChangeStateEntry *qdev_add_vm_change_state_handler(DeviceState *dev,
+ VMChangeStateHandler *cb,
+ void *opaque)
+{
+ return NULL;
+}
+
+void hmp_handle_error(Monitor *mon, Error *err)
+{
+}
diff --git a/stubs/net-stub.c b/stubs/net-stub.c
new file mode 100644
index 0000000000..cb2274ba40
--- /dev/null
+++ b/stubs/net-stub.c
@@ -0,0 +1,31 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "net/net.h"
+
+int qemu_find_net_clients_except(const char *id, NetClientState **ncs,
+ NetClientDriver type, int max)
+{
+ return -ENOSYS;
+}
+
+NetClientState *net_hub_port_find(int hub_id)
+{
+ return NULL;
+}
+
+int net_hub_id_for_client(NetClientState *nc, int *id)
+{
+ return -ENOSYS;
+}
+
+int qemu_show_nic_models(const char *arg, const char *const *models)
+{
+ return -ENOSYS;
+}
+
+int qemu_find_nic_model(NICInfo *nd, const char * const *models,
+ const char *default_model)
+{
+ return -ENOSYS;
+}
+
diff --git a/stubs/replay.c b/stubs/replay.c
index 5974ec1f50..2e3feee6a9 100644
--- a/stubs/replay.c
+++ b/stubs/replay.c
@@ -88,3 +88,17 @@ int replay_read_random(void *buf, size_t len)
{
return 0;
}
+
+bool replay_has_checkpoint(void)
+{
+ return false;
+}
+
+int replay_get_instructions(void)
+{
+ return 0;
+}
+
+void replay_account_executed_instructions(void)
+{
+}
diff --git a/stubs/vl-stub.c b/stubs/vl-stub.c
new file mode 100644
index 0000000000..fff72be201
--- /dev/null
+++ b/stubs/vl-stub.c
@@ -0,0 +1,79 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/uuid.h"
+#include "sysemu/sysemu.h"
+#include "exec/cpu-common.h"
+#include "exec/gdbstub.h"
+#include "sysemu/replay.h"
+#include "disas/disas.h"
+#include "sysemu/runstate.h"
+
+bool tcg_allowed;
+bool xen_allowed;
+bool boot_strict;
+bool qemu_uuid_set;
+
+int mem_prealloc;
+int smp_cpus;
+int vga_interface_type = VGA_NONE;
+int smp_cores = 1;
+int smp_threads = 1;
+int icount_align_option;
+int boot_menu;
+
+unsigned int max_cpus;
+const uint32_t arch_type;
+const char *mem_path;
+uint8_t qemu_extra_params_fw[2];
+uint8_t *boot_splash_filedata;
+size_t boot_splash_filedata_size;
+struct syminfo *syminfos;
+
+ram_addr_t ram_size;
+MachineState *current_machine;
+QemuUUID qemu_uuid;
+
+int runstate_is_running(void)
+{
+ return 0;
+}
+
+void runstate_set(RunState new_state)
+{
+}
+
+void vm_state_notify(int running, RunState state)
+{
+}
+
+bool qemu_vmstop_requested(RunState *r)
+{
+ return false;
+}
+
+void qemu_system_debug_request(void)
+{
+}
+
+char *qemu_find_file(int type, const char *name)
+{
+ return NULL;
+}
+
+void gdb_set_stop_cpu(CPUState *cpu)
+{
+}
+
+void replay_enable_events(void)
+{
+}
+
+void replay_disable_events(void)
+{
+}
+
+#ifdef TARGET_I386
+void x86_cpu_list(void)
+{
+}
+#endif
diff --git a/stubs/vmstate.c b/stubs/vmstate.c
index cc4fe41dfc..c7c015ac58 100644
--- a/stubs/vmstate.c
+++ b/stubs/vmstate.c
@@ -1,7 +1,9 @@
#include "qemu/osdep.h"
#include "migration/vmstate.h"
+#include "migration/misc.h"
const VMStateDescription vmstate_dummy = {};
+const VMStateInfo vmstate_info_timer;
int vmstate_register_with_alias_id(VMStateIf *obj,
uint32_t instance_id,
@@ -23,3 +25,20 @@ bool vmstate_check_only_migratable(const VMStateDescription *vmsd)
{
return true;
}
+
+void vmstate_register_ram(MemoryRegion *mr, DeviceState *dev)
+{
+}
+
+void vmstate_unregister_ram(MemoryRegion *mr, DeviceState *dev)
+{
+}
+
+void vmstate_register_ram_global(MemoryRegion *mr)
+{
+}
+
+bool migration_is_idle(void)
+{
+ return true;
+}
diff --git a/stubs/xen-mapcache.c b/stubs/xen-mapcache.c
new file mode 100644
index 0000000000..af5c031727
--- /dev/null
+++ b/stubs/xen-mapcache.c
@@ -0,0 +1,22 @@
+#include "qemu/osdep.h"
+#include "exec/hwaddr.h"
+#include "exec/cpu-common.h"
+#include "sysemu/xen-mapcache.h"
+
+#ifdef CONFIG_XEN
+
+void xen_invalidate_map_cache_entry(uint8_t *buffer)
+{
+}
+
+uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size, uint8_t lock, bool dma)
+{
+ return NULL;
+}
+
+ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
+{
+ return 0;
+}
+
+#endif
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 09/36] multi-process: Add config option for multi-process QEMU
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (7 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-24 13:47 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 10/36] multi-process: build system for remote device process elena.ufimtseva
` (29 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Add a configuration option to separate multi-process code
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
configure | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/configure b/configure
index 23b5e93752..913c78d4ef 100755
--- a/configure
+++ b/configure
@@ -509,6 +509,7 @@ libpmem=""
default_devices="yes"
plugins="no"
fuzzing="no"
+mpqemu="no"
supported_cpu="no"
supported_os="no"
@@ -1601,6 +1602,10 @@ for opt do
;;
--gdb=*) gdb_bin="$optarg"
;;
+ --enable-mpqemu) mpqemu=yes
+ ;;
+ --disable-mpqemu) mpqemu=no
+ ;;
*)
echo "ERROR: unknown option $opt"
echo "Try '$0 --help' for more information"
@@ -1894,6 +1899,7 @@ disabled with --disable-FEATURE, default is enabled if available:
debug-mutex mutex debugging support
libpmem libpmem support
xkbcommon xkbcommon support
+ mpqemu multi-process QEMU support
NOTE: The object files are built at the place where configure is launched
EOF
@@ -6733,6 +6739,7 @@ echo "default devices $default_devices"
echo "plugin support $plugins"
echo "fuzzing support $fuzzing"
echo "gdb $gdb_bin"
+echo "multiprocess QEMU $mpqemu"
if test "$supported_cpu" = "no"; then
echo
@@ -7551,6 +7558,10 @@ if test "$libpmem" = "yes" ; then
echo "CONFIG_LIBPMEM=y" >> $config_host_mak
fi
+if test "$mpqemu" = "yes" ; then
+ echo "CONFIG_MPQEMU=y" >> $config_host_mak
+fi
+
if test "$bochs" = "yes" ; then
echo "CONFIG_BOCHS=y" >> $config_host_mak
fi
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 10/36] multi-process: build system for remote device process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (8 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 09/36] multi-process: Add config option for multi-process QEMU elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-24 15:04 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object elena.ufimtseva
` (28 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Modify Makefile to support the building of the remote
device process. Implements main() function of remote
device process.
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 8 ++++++
Makefile | 2 ++
Makefile.objs | 27 ++++++++++++++++++
Makefile.target | 61 ++++++++++++++++++++++++++++++++++++++++-
accel/Makefile.objs | 2 ++
backends/Makefile.objs | 2 ++
block/Makefile.objs | 2 ++
hw/Makefile.objs | 7 +++++
hw/block/Makefile.objs | 2 ++
hw/core/Makefile.objs | 18 ++++++++++++
hw/nvram/Makefile.objs | 2 ++
hw/pci/Makefile.objs | 4 +++
hw/scsi/Makefile.objs | 2 ++
migration/Makefile.objs | 2 ++
qom/Makefile.objs | 3 ++
remote/Makefile.objs | 1 +
remote/remote-main.c | 23 ++++++++++++++++
stubs/replay.c | 4 +++
18 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 remote/Makefile.objs
create mode 100644 remote/remote-main.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c5fba124e4..965f34d4f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2850,6 +2850,14 @@ S: Maintained
F: hw/semihosting/
F: include/hw/semihosting/
+Multi-process QEMU
+M: Jagannathan Raman <jag.raman@oracle.com>
+M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
+M: John G Johnson <john.g.johnson@oracle.com>
+S: Maintained
+F: remote/Makefile.objs
+F: remote/remote-main.c
+
Build and test automation
-------------------------
Build and test automation
diff --git a/Makefile b/Makefile
index 8a9113e666..69337d6f8c 100644
--- a/Makefile
+++ b/Makefile
@@ -474,6 +474,8 @@ dummy := $(call unnest-vars,, \
qom-obj-y \
io-obj-y \
common-obj-y \
+ remote-pci-obj-y \
+ remote-lsi-obj-y \
common-obj-m \
trace-obj-y)
diff --git a/Makefile.objs b/Makefile.objs
index f29c60c59d..f6654633b4 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -21,6 +21,33 @@ block-obj-$(CONFIG_REPLICATION) += replication.o
block-obj-m = block/
+#########################################################
+# remote-pci-obj-y is common code used by remote devices
+
+remote-pci-obj-$(CONFIG_MPQEMU) += hw/
+remote-pci-obj-$(CONFIG_MPQEMU) += qom/
+remote-pci-obj-$(CONFIG_MPQEMU) += backends/
+remote-pci-obj-$(CONFIG_MPQEMU) += block/
+remote-pci-obj-$(CONFIG_MPQEMU) += migration/
+remote-pci-obj-$(CONFIG_MPQEMU) += remote/
+remote-pci-obj-$(CONFIG_MPQEMU) += accel/
+
+remote-pci-obj-$(CONFIG_MPQEMU) += cpus-common.o
+remote-pci-obj-$(CONFIG_MPQEMU) += dma-helpers.o
+remote-pci-obj-$(CONFIG_MPQEMU) += blockdev.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qdev-monitor.o
+remote-pci-obj-$(CONFIG_MPQEMU) += bootdevice.o
+remote-pci-obj-$(CONFIG_MPQEMU) += iothread.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qemu-parse.o
+
+##############################################################
+# remote-lsi-obj-y is code used to implement remote LSI device
+
+remote-lsi-obj-$(CONFIG_MPQEMU) += hw/
+
+#######################################################################
+# crypto-obj-y is code used by both qemu system emulation and qemu-img
+
crypto-obj-y = crypto/
io-obj-y = io/
diff --git a/Makefile.target b/Makefile.target
index 8ed1eba95b..70fa1eeca5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -36,7 +36,17 @@ QEMU_PROG_BUILD = $(QEMU_PROG)
endif
endif
+ifdef CONFIG_MPQEMU
+SCSI_DEV_PROG=qemu-scsi-dev
+SCSI_DEV_BUILD = $(SCSI_DEV_PROG)
+endif
+
PROGS=$(QEMU_PROG) $(QEMU_PROGW)
+
+ifeq ($(TARGET_NAME)-$(CONFIG_MPQEMU)-$(CONFIG_USER_ONLY), x86_64-y-)
+PROGS += $(SCSI_DEV_PROG)
+endif
+
STPFILES=
config-target.h: config-target.h-timestamp
@@ -121,6 +131,20 @@ LIBS := $(libs_cpu) $(LIBS)
obj-$(CONFIG_PLUGIN) += plugins/
+ifeq ($(TARGET_NAME)-$(CONFIG_MPQEMU)-$(CONFIG_USER_ONLY), x86_64-y-)
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/kvm-stub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/tcg-stub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/hax-stub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/whpx-stub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/vl-stub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/net-stub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/monitor.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/replay.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/xen-mapcache.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/audio.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/monitor.o
+endif
+
#########################################################
# Linux user emulator target
@@ -179,6 +203,20 @@ endif # CONFIG_SOFTMMU
dummy := $(call unnest-vars,,obj-y)
all-obj-y := $(obj-y)
+dummy := $(call unnest-vars,..,remote-pci-tgt-obj-y)
+all-remote-pci-obj-y := $(remote-pci-tgt-obj-y)
+
+ifeq ($(TARGET_NAME)-$(CONFIG_MPQEMU)-$(CONFIG_USER_ONLY), x86_64-y-)
+all-remote-pci-obj-y += memory.o
+all-remote-pci-obj-y += exec.o
+all-remote-pci-obj-y += exec-vary.o
+all-remote-pci-obj-y += ioport.o
+all-remote-pci-obj-y += cpus.o
+endif
+
+remote-pci-obj-y :=
+remote-lsi-obj-y :=
+
include $(SRC_PATH)/Makefile.objs
dummy := $(call unnest-vars,.., \
authz-obj-y \
@@ -189,7 +227,10 @@ dummy := $(call unnest-vars,.., \
qom-obj-y \
io-obj-y \
common-obj-y \
- common-obj-m)
+ common-obj-m \
+ remote-pci-obj-y \
+ remote-lsi-obj-y)
+
all-obj-y += $(common-obj-y)
all-obj-y += $(qom-obj-y)
all-obj-$(CONFIG_SOFTMMU) += $(authz-obj-y)
@@ -197,8 +238,19 @@ all-obj-$(CONFIG_SOFTMMU) += $(block-obj-y) $(chardev-obj-y)
all-obj-$(CONFIG_SOFTMMU) += $(crypto-obj-y)
all-obj-$(CONFIG_SOFTMMU) += $(io-obj-y)
+all-remote-pci-obj-y += $(authz-obj-y)
+all-remote-pci-obj-y += $(block-obj-y)
+all-remote-pci-obj-y += $(crypto-obj-y)
+all-remote-pci-obj-y += $(io-obj-y)
+all-remote-pci-obj-y += $(chardev-obj-y)
+all-remote-pci-obj-y += $(remote-pci-obj-y)
+
+
+all-remote-lsi-obj-y += $(all-remote-pci-obj-y) $(remote-lsi-obj-y)
+
ifdef CONFIG_SOFTMMU
$(QEMU_PROG_BUILD): config-devices.mak
+$(SCSI_DEV_BUILD): config-devices.mak
endif
COMMON_LDADDS = ../libqemuutil.a
@@ -211,6 +263,13 @@ ifdef CONFIG_DARWIN
$(call quiet-command,SetFile -a C $@,"SETFILE","$(TARGET_DIR)$@")
endif
+$(SCSI_DEV_BUILD): $(all-remote-lsi-obj-y) $(COMMON_LDADDS)
+ $(call LINK, $(filter-out %.mak, $^))
+ifdef CONFIG_DARWIN
+ $(call quiet-command,Rez -append $(SRC_PATH)/pc-bios/qemu.rsrc -o $@,"REZ","$(TARGET_DIR)$@")
+ $(call quiet-command,SetFile -a C $@,"SETFILE","$(TARGET_DIR)$@")
+endif
+
gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh
$(call quiet-command,rm -f $@ && $(SHELL) $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES),"GEN","$(TARGET_DIR)$@")
diff --git a/accel/Makefile.objs b/accel/Makefile.objs
index 17e5ac6061..e312dd4f01 100644
--- a/accel/Makefile.objs
+++ b/accel/Makefile.objs
@@ -3,3 +3,5 @@ obj-$(call land,$(CONFIG_SOFTMMU),$(CONFIG_POSIX)) += qtest.o
obj-$(CONFIG_KVM) += kvm/
obj-$(CONFIG_TCG) += tcg/
obj-y += stubs/
+
+remote-pci-obj-$(CONFIG_MPQEMU) += accel.o
diff --git a/backends/Makefile.objs b/backends/Makefile.objs
index 28a847cd57..947cde39ac 100644
--- a/backends/Makefile.objs
+++ b/backends/Makefile.objs
@@ -21,3 +21,5 @@ common-obj-$(CONFIG_LINUX) += hostmem-memfd.o
common-obj-$(CONFIG_GIO) += dbus-vmstate.o
dbus-vmstate.o-cflags = $(GIO_CFLAGS)
dbus-vmstate.o-libs = $(GIO_LIBS)
+
+remote-pci-obj-$(CONFIG_MPQEMU) += hostmem.o
diff --git a/block/Makefile.objs b/block/Makefile.objs
index 3635b6b4c1..3e7513967c 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -74,3 +74,5 @@ io_uring.o-cflags := $(LINUX_IO_URING_CFLAGS)
io_uring.o-libs := $(LINUX_IO_URING_LIBS)
parallels.o-cflags := $(LIBXML2_CFLAGS)
parallels.o-libs := $(LIBXML2_LIBS)
+
+remote-pci-obj-$(CONFIG_MPQEMU) += stream.o
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 660e2b4373..af9235b6f2 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -44,3 +44,10 @@ endif
common-obj-y += $(devices-dirs-y)
obj-y += $(devices-dirs-y)
+
+remote-pci-obj-$(CONFIG_MPQEMU) += core/
+remote-pci-obj-$(CONFIG_MPQEMU) += block/
+remote-pci-obj-$(CONFIG_MPQEMU) += pci/
+remote-pci-obj-$(CONFIG_MPQEMU) += nvram/
+
+remote-lsi-obj-$(CONFIG_MPQEMU) += scsi/
diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index 4b4a2b338d..0b4644f472 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -16,3 +16,5 @@ obj-$(CONFIG_VIRTIO_BLK) += virtio-blk.o
obj-$(CONFIG_VHOST_USER_BLK) += vhost-user-blk.o
obj-y += dataplane/
+
+remote-pci-obj-$(CONFIG_MPQEMU) += block.o cdrom.o hd-geometry.o
diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
index 6215e7c208..e3e80848c8 100644
--- a/hw/core/Makefile.objs
+++ b/hw/core/Makefile.objs
@@ -31,3 +31,21 @@ common-obj-$(CONFIG_OR_IRQ) += or-irq.o
common-obj-$(CONFIG_SPLIT_IRQ) += split-irq.o
common-obj-$(CONFIG_PLATFORM_BUS) += platform-bus.o
common-obj-$(CONFIG_GENERIC_LOADER) += generic-loader.o
+
+remote-pci-obj-$(CONFIG_MPQEMU) += qdev-properties.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qdev.o
+remote-pci-obj-$(CONFIG_MPQEMU) += bus.o
+remote-pci-obj-$(CONFIG_MPQEMU) += irq.o
+remote-pci-obj-$(CONFIG_MPQEMU) += hotplug.o
+remote-pci-obj-$(CONFIG_MPQEMU) += machine.o
+remote-pci-obj-$(CONFIG_MPQEMU) += fw-path-provider.o
+remote-pci-obj-$(CONFIG_MPQEMU) += reset.o
+remote-pci-obj-$(CONFIG_MPQEMU) += sysbus.o
+remote-pci-obj-$(CONFIG_MPQEMU) += loader.o
+remote-pci-obj-$(CONFIG_MPQEMU) += nmi.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qdev-properties-system.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qdev-fw.o
+remote-pci-obj-$(CONFIG_MPQEMU) += numa.o
+remote-pci-obj-$(CONFIG_MPQEMU) += cpu.o
+remote-pci-obj-$(CONFIG_MPQEMU) += vmstate-if.o
+remote-pci-obj-$(CONFIG_MPQEMU) += resettable.o
diff --git a/hw/nvram/Makefile.objs b/hw/nvram/Makefile.objs
index f3ad921382..4d2d809106 100644
--- a/hw/nvram/Makefile.objs
+++ b/hw/nvram/Makefile.objs
@@ -6,3 +6,5 @@ common-obj-$(CONFIG_CHRP_NVRAM) += chrp_nvram.o
common-obj-$(CONFIG_MAC_NVRAM) += mac_nvram.o
common-obj-$(CONFIG_NRF51_SOC) += nrf51_nvm.o
obj-$(CONFIG_PSERIES) += spapr_nvram.o
+
+remote-pci-obj-$(CONFIG_MPQEMU) += fw_cfg.o
diff --git a/hw/pci/Makefile.objs b/hw/pci/Makefile.objs
index c78f2fb24b..955be54472 100644
--- a/hw/pci/Makefile.objs
+++ b/hw/pci/Makefile.objs
@@ -12,3 +12,7 @@ common-obj-$(CONFIG_PCI_EXPRESS) += pcie_port.o pcie_host.o
common-obj-$(call lnot,$(CONFIG_PCI)) += pci-stub.o
common-obj-$(CONFIG_ALL) += pci-stub.o
+
+remote-pci-obj-$(CONFIG_MPQEMU) += pci.o pci_bridge.o
+remote-pci-obj-$(CONFIG_MPQEMU) += msi.o msix.o
+remote-pci-obj-$(CONFIG_MPQEMU) += pcie.o
diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
index 54b36ed8b1..ef97770922 100644
--- a/hw/scsi/Makefile.objs
+++ b/hw/scsi/Makefile.objs
@@ -13,3 +13,5 @@ obj-y += virtio-scsi.o virtio-scsi-dataplane.o
obj-$(CONFIG_VHOST_SCSI) += vhost-scsi-common.o vhost-scsi.o
obj-$(CONFIG_VHOST_USER_SCSI) += vhost-scsi-common.o vhost-user-scsi.o
endif
+
+remote-lsi-obj-$(CONFIG_MPQEMU) += scsi-generic.o scsi-bus.o lsi53c895a.o scsi-disk.o emulation.o
diff --git a/migration/Makefile.objs b/migration/Makefile.objs
index 0fc619e380..ad33d77d0b 100644
--- a/migration/Makefile.objs
+++ b/migration/Makefile.objs
@@ -16,3 +16,5 @@ common-obj-$(CONFIG_RDMA) += rdma.o
common-obj-$(CONFIG_LIVE_BLOCK_MIGRATION) += block.o
rdma.o-libs := $(RDMA_LIBS)
+
+remote-pci-obj-$(CONFIG_MPQEMU) += qemu-file.o vmstate.o qjson.o vmstate-types.o
diff --git a/qom/Makefile.objs b/qom/Makefile.objs
index 1b45d104ba..7e9455db90 100644
--- a/qom/Makefile.objs
+++ b/qom/Makefile.objs
@@ -3,3 +3,6 @@ qom-obj-y += object_interfaces.o
common-obj-$(CONFIG_SOFTMMU) += qom-hmp-cmds.o qom-qmp-cmds.o
storage-daemon-obj-y += qom-qmp-cmds.o
+
+remote-pci-obj-$(CONFIG_MPQEMU) += object.o qom-qobject.o container.o
+remote-pci-obj-$(CONFIG_MPQEMU) += object_interfaces.o
diff --git a/remote/Makefile.objs b/remote/Makefile.objs
new file mode 100644
index 0000000000..a9b2256b2a
--- /dev/null
+++ b/remote/Makefile.objs
@@ -0,0 +1 @@
+remote-pci-obj-$(CONFIG_MPQEMU) += remote-main.o
diff --git a/remote/remote-main.c b/remote/remote-main.c
new file mode 100644
index 0000000000..7c0764ad01
--- /dev/null
+++ b/remote/remote-main.c
@@ -0,0 +1,23 @@
+/*
+ * Remote device initialization
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include <stdio.h>
+
+#include "qemu/module.h"
+
+int main(int argc, char *argv[])
+{
+ module_call_init(MODULE_INIT_QOM);
+
+ return 0;
+}
diff --git a/stubs/replay.c b/stubs/replay.c
index 2e3feee6a9..9b53c0cb37 100644
--- a/stubs/replay.c
+++ b/stubs/replay.c
@@ -102,3 +102,7 @@ int replay_get_instructions(void)
void replay_account_executed_instructions(void)
{
}
+
+void replay_add_blocker(Error *reason)
+{
+}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (9 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 10/36] multi-process: build system for remote device process elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 8:56 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints elena.ufimtseva
` (27 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Defines mpqemu-link object which forms the communication link between
QEMU & emulation program.
Adds functions to configure members of mpqemu-link object instance.
Adds functions to send and receive messages over the communication
channel.
Adds GMainLoop to handle events received on the communication channel.
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 2 +
include/io/mpqemu-link.h | 127 ++++++++++++++++
io/Makefile.objs | 2 +
io/mpqemu-link.c | 312 +++++++++++++++++++++++++++++++++++++++
4 files changed, 443 insertions(+)
create mode 100644 include/io/mpqemu-link.h
create mode 100644 io/mpqemu-link.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 965f34d4f9..93ad693da4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2857,6 +2857,8 @@ M: John G Johnson <john.g.johnson@oracle.com>
S: Maintained
F: remote/Makefile.objs
F: remote/remote-main.c
+F: include/io/mpqemu-link.h
+F: io/mpqemu-link.c
Build and test automation
-------------------------
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
new file mode 100644
index 0000000000..af401e640c
--- /dev/null
+++ b/include/io/mpqemu-link.h
@@ -0,0 +1,127 @@
+/*
+ * Communication channel between QEMU and remote device process
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef MPQEMU_LINK_H
+#define MPQEMU_LINK_H
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "qom/object.h"
+#include "qemu/thread.h"
+
+#define TYPE_MPQEMU_LINK "mpqemu-link"
+#define MPQEMU_LINK(obj) \
+ OBJECT_CHECK(MPQemuLinkState, (obj), TYPE_MPQEMU_LINK)
+
+#define REMOTE_MAX_FDS 8
+
+#define MPQEMU_MSG_HDR_SIZE offsetof(MPQemuMsg, data1.u64)
+
+/**
+ * mpqemu_cmd_t:
+ *
+ * proc_cmd_t enum type to specify the command to be executed on the remote
+ * device.
+ */
+typedef enum {
+ INIT = 0,
+ MAX,
+} mpqemu_cmd_t;
+
+/**
+ * MPQemuMsg:
+ * @cmd: The remote command
+ * @bytestream: Indicates if the data to be shared is structured (data1)
+ * or unstructured (data2)
+ * @size: Size of the data to be shared
+ * @data1: Structured data
+ * @fds: File descriptors to be shared with remote device
+ * @data2: Unstructured data
+ *
+ * MPQemuMsg Format of the message sent to the remote device from QEMU.
+ *
+ */
+typedef struct {
+ mpqemu_cmd_t cmd;
+ int bytestream;
+ size_t size;
+
+ union {
+ uint64_t u64;
+ } data1;
+
+ int fds[REMOTE_MAX_FDS];
+ int num_fds;
+
+ uint8_t *data2;
+} MPQemuMsg;
+
+/**
+ * MPQemuChannel:
+ * @gsrc: GSource object to be used by loop
+ * @gpfd: GPollFD object containing the socket & events to monitor
+ * @sock: Socket to send/receive communication, same as the one in gpfd
+ * @send_lock: Mutex to synchronize access to the send stream
+ * @recv_lock: Mutex to synchronize access to the recv stream
+ *
+ * Defines the channel that make up the communication link
+ * between QEMU and remote process
+ */
+
+typedef struct MPQemuChannel {
+ GSource gsrc;
+ GPollFD gpfd;
+ int sock;
+ QemuMutex send_lock;
+ QemuMutex recv_lock;
+} MPQemuChannel;
+
+typedef struct MPQemuLinkState MPQemuLinkState;
+
+typedef void (*mpqemu_link_callback)(GIOCondition cond, MPQemuLinkState *link,
+ MPQemuChannel *chan);
+
+/*
+ * MPQemuLinkState Instance info. of the communication
+ * link between QEMU and remote process. The Link could
+ * be made up of multiple channels.
+ *
+ * ctx GMainContext to be used for communication
+ * loop Main loop that would be used to poll for incoming data
+ * com Communication channel to transport control messages
+ *
+ */
+
+struct MPQemuLinkState {
+ Object obj;
+
+ GMainContext *ctx;
+ GMainLoop *loop;
+
+ MPQemuChannel *com;
+
+ mpqemu_link_callback callback;
+};
+
+MPQemuLinkState *mpqemu_link_create(void);
+void mpqemu_link_finalize(MPQemuLinkState *s);
+
+void mpqemu_msg_send(MPQemuMsg *msg, MPQemuChannel *chan);
+int mpqemu_msg_recv(MPQemuMsg *msg, MPQemuChannel *chan);
+
+void mpqemu_init_channel(MPQemuLinkState *s, MPQemuChannel **chan, int fd);
+void mpqemu_destroy_channel(MPQemuChannel *chan);
+void mpqemu_link_set_callback(MPQemuLinkState *s,
+ mpqemu_link_callback callback);
+void mpqemu_start_coms(MPQemuLinkState *s, MPQemuChannel* chan);
+bool mpqemu_msg_valid(MPQemuMsg *msg);
+
+#endif
diff --git a/io/Makefile.objs b/io/Makefile.objs
index 9a20fce4ed..5875ab0697 100644
--- a/io/Makefile.objs
+++ b/io/Makefile.objs
@@ -10,3 +10,5 @@ io-obj-y += channel-util.o
io-obj-y += dns-resolver.o
io-obj-y += net-listener.o
io-obj-y += task.o
+
+io-obj-$(CONFIG_MPQEMU) += mpqemu-link.o
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
new file mode 100644
index 0000000000..48f53a8928
--- /dev/null
+++ b/io/mpqemu-link.c
@@ -0,0 +1,312 @@
+/*
+ * Communication channel between QEMU and remote device process
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "qemu/module.h"
+#include "io/mpqemu-link.h"
+#include "qemu/log.h"
+#include "qemu/lockable.h"
+
+GSourceFuncs gsrc_funcs;
+
+static void mpqemu_link_inst_init(Object *obj)
+{
+ MPQemuLinkState *s = MPQEMU_LINK(obj);
+
+ s->ctx = g_main_context_default();
+ s->loop = g_main_loop_new(s->ctx, FALSE);
+}
+
+static const TypeInfo mpqemu_link_info = {
+ .name = TYPE_MPQEMU_LINK,
+ .parent = TYPE_OBJECT,
+ .instance_size = sizeof(MPQemuLinkState),
+ .instance_init = mpqemu_link_inst_init,
+};
+
+static void mpqemu_link_register_types(void)
+{
+ type_register_static(&mpqemu_link_info);
+}
+
+type_init(mpqemu_link_register_types)
+
+MPQemuLinkState *mpqemu_link_create(void)
+{
+ MPQemuLinkState *link = MPQEMU_LINK(object_new(TYPE_MPQEMU_LINK));
+
+ link->com = NULL;
+
+ return link;
+}
+
+void mpqemu_link_finalize(MPQemuLinkState *s)
+{
+ g_main_loop_unref(s->loop);
+ g_main_context_unref(s->ctx);
+ g_main_loop_quit(s->loop);
+
+ mpqemu_destroy_channel(s->com);
+
+ object_unref(OBJECT(s));
+}
+
+void mpqemu_msg_send(MPQemuMsg *msg, MPQemuChannel *chan)
+{
+ int rc;
+ uint8_t *data;
+ union {
+ char control[CMSG_SPACE(REMOTE_MAX_FDS * sizeof(int))];
+ struct cmsghdr align;
+ } u;
+ struct msghdr hdr;
+ struct cmsghdr *chdr;
+ int sock = chan->sock;
+ QemuMutex *lock = &chan->send_lock;
+
+ struct iovec iov = {
+ .iov_base = (char *) msg,
+ .iov_len = MPQEMU_MSG_HDR_SIZE,
+ };
+
+ memset(&hdr, 0, sizeof(hdr));
+ memset(&u, 0, sizeof(u));
+
+ hdr.msg_iov = &iov;
+ hdr.msg_iovlen = 1;
+
+ if (msg->num_fds > REMOTE_MAX_FDS) {
+ qemu_log_mask(LOG_REMOTE_DEBUG, "%s: Max FDs exceeded\n", __func__);
+ return;
+ }
+
+ if (msg->num_fds > 0) {
+ size_t fdsize = msg->num_fds * sizeof(int);
+
+ hdr.msg_control = &u;
+ hdr.msg_controllen = sizeof(u);
+
+ chdr = CMSG_FIRSTHDR(&hdr);
+ chdr->cmsg_len = CMSG_LEN(fdsize);
+ chdr->cmsg_level = SOL_SOCKET;
+ chdr->cmsg_type = SCM_RIGHTS;
+ memcpy(CMSG_DATA(chdr), msg->fds, fdsize);
+ hdr.msg_controllen = CMSG_SPACE(fdsize);
+ }
+
+ WITH_QEMU_LOCK_GUARD(lock) {
+ do {
+ rc = sendmsg(sock, &hdr, 0);
+ } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+
+ if (rc < 0) {
+ qemu_log_mask(LOG_REMOTE_DEBUG, "%s - sendmsg rc is %d, "
+ "errno is %d, sock %d\n", __func__, rc, errno, sock);
+ return;
+ }
+
+ if (msg->bytestream) {
+ data = msg->data2;
+ } else {
+ data = (uint8_t *)msg + MPQEMU_MSG_HDR_SIZE;
+ }
+
+ do {
+ rc = write(sock, data, msg->size);
+ } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+ }
+}
+
+
+int mpqemu_msg_recv(MPQemuMsg *msg, MPQemuChannel *chan)
+{
+ int rc;
+ uint8_t *data;
+ union {
+ char control[CMSG_SPACE(REMOTE_MAX_FDS * sizeof(int))];
+ struct cmsghdr align;
+ } u;
+ struct msghdr hdr;
+ struct cmsghdr *chdr;
+ size_t fdsize;
+ int sock = chan->sock;
+ QemuMutex *lock = &chan->recv_lock;
+
+ struct iovec iov = {
+ .iov_base = (char *) msg,
+ .iov_len = MPQEMU_MSG_HDR_SIZE,
+ };
+
+ memset(&hdr, 0, sizeof(hdr));
+ memset(&u, 0, sizeof(u));
+
+ hdr.msg_iov = &iov;
+ hdr.msg_iovlen = 1;
+ hdr.msg_control = &u;
+ hdr.msg_controllen = sizeof(u);
+
+ WITH_QEMU_LOCK_GUARD(lock) {
+ do {
+ rc = recvmsg(sock, &hdr, 0);
+ } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+
+ if (rc < 0) {
+ qemu_log_mask(LOG_REMOTE_DEBUG, "%s - recvmsg rc is %d, "
+ "errno is %d, sock %d\n", __func__, rc, errno, sock);
+ return rc;
+ }
+
+ msg->num_fds = 0;
+ for (chdr = CMSG_FIRSTHDR(&hdr); chdr != NULL;
+ chdr = CMSG_NXTHDR(&hdr, chdr)) {
+ if ((chdr->cmsg_level == SOL_SOCKET) &&
+ (chdr->cmsg_type == SCM_RIGHTS)) {
+ fdsize = chdr->cmsg_len - CMSG_LEN(0);
+ msg->num_fds = fdsize / sizeof(int);
+ if (msg->num_fds > REMOTE_MAX_FDS) {
+ qemu_log_mask(LOG_REMOTE_DEBUG,
+ "%s: Max FDs exceeded\n", __func__);
+ return -ERANGE;
+ }
+
+ memcpy(msg->fds, CMSG_DATA(chdr), fdsize);
+ break;
+ }
+ }
+
+ if (msg->bytestream) {
+ if (!msg->size) {
+ qemu_mutex_unlock(lock);
+ return -EINVAL;
+ }
+
+ msg->data2 = calloc(1, msg->size);
+ data = msg->data2;
+ } else {
+ data = (uint8_t *)&msg->data1;
+ }
+
+ if (msg->size) {
+ do {
+ rc = read(sock, data, msg->size);
+ } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
+ }
+ }
+ return rc;
+}
+
+static gboolean mpqemu_link_handler_prepare(GSource *gsrc, gint *timeout)
+{
+ g_assert(timeout);
+
+ *timeout = -1;
+
+ return FALSE;
+}
+
+static gboolean mpqemu_link_handler_check(GSource *gsrc)
+{
+ MPQemuChannel *chan = (MPQemuChannel *)gsrc;
+
+ return chan->gpfd.events & chan->gpfd.revents;
+}
+
+static gboolean mpqemu_link_handler_dispatch(GSource *gsrc, GSourceFunc func,
+ gpointer data)
+{
+ MPQemuLinkState *s = (MPQemuLinkState *)data;
+ MPQemuChannel *chan = (MPQemuChannel *)gsrc;
+
+ s->callback(chan->gpfd.revents, s, chan);
+
+ if ((chan->gpfd.revents & G_IO_HUP) || (chan->gpfd.revents & G_IO_ERR)) {
+ return G_SOURCE_REMOVE;
+ }
+
+ return G_SOURCE_CONTINUE;
+}
+
+void mpqemu_link_set_callback(MPQemuLinkState *s, mpqemu_link_callback callback)
+{
+ s->callback = callback;
+}
+
+void mpqemu_init_channel(MPQemuLinkState *s, MPQemuChannel **chan, int fd)
+{
+ MPQemuChannel *src;
+
+ gsrc_funcs = (GSourceFuncs){
+ .prepare = mpqemu_link_handler_prepare,
+ .check = mpqemu_link_handler_check,
+ .dispatch = mpqemu_link_handler_dispatch,
+ .finalize = NULL,
+ };
+
+ src = (MPQemuChannel *)g_source_new(&gsrc_funcs, sizeof(MPQemuChannel));
+
+ src->sock = fd;
+ qemu_mutex_init(&src->send_lock);
+ qemu_mutex_init(&src->recv_lock);
+
+ g_source_set_callback(&src->gsrc, NULL, (gpointer)s, NULL);
+ src->gpfd.fd = fd;
+ src->gpfd.events = G_IO_IN | G_IO_HUP | G_IO_ERR;
+ g_source_add_poll(&src->gsrc, &src->gpfd);
+
+ *chan = src;
+}
+
+void mpqemu_destroy_channel(MPQemuChannel *chan)
+{
+ g_source_unref(&chan->gsrc);
+ close(chan->sock);
+ qemu_mutex_destroy(&chan->send_lock);
+ qemu_mutex_destroy(&chan->recv_lock);
+}
+
+void mpqemu_start_coms(MPQemuLinkState *s, MPQemuChannel* chan)
+{
+ g_assert(g_source_attach(&chan->gsrc, s->ctx));
+
+ g_main_loop_run(s->loop);
+}
+
+bool mpqemu_msg_valid(MPQemuMsg *msg)
+{
+ if (msg->cmd >= MAX) {
+ return false;
+ }
+
+ if (msg->bytestream) {
+ if (!msg->data2) {
+ return false;
+ }
+ } else {
+ if (msg->data2) {
+ return false;
+ }
+ }
+
+ /* Verify FDs. */
+ if (msg->num_fds >= REMOTE_MAX_FDS) {
+ return false;
+ }
+ if (msg->num_fds > 0) {
+ for (int i = 0; i < msg->num_fds; i++) {
+ if (fcntl(msg->fds[i], F_GETFL) == -1) {
+ return false;
+ }
+ }
+ }
+
+ return true;
+}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (10 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 10:21 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device elena.ufimtseva
` (26 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
In some cases, for example MMIO read, QEMU has to wait for the remote to
complete a command before proceeding. An eventfd based mechanism is
added to synchronize QEMU & remote process.
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
include/io/mpqemu-link.h | 7 +++++
io/mpqemu-link.c | 61 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+)
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index af401e640c..ef95599bca 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -124,4 +124,11 @@ void mpqemu_link_set_callback(MPQemuLinkState *s,
void mpqemu_start_coms(MPQemuLinkState *s, MPQemuChannel* chan);
bool mpqemu_msg_valid(MPQemuMsg *msg);
+#define GET_REMOTE_WAIT eventfd(0, EFD_CLOEXEC)
+#define PUT_REMOTE_WAIT(wait) close(wait)
+#define PROXY_LINK_WAIT_DONE 1
+
+uint64_t wait_for_remote(int efd);
+void notify_proxy(int fd, uint64_t val);
+
#endif
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
index 48f53a8928..cc0a7aecd4 100644
--- a/io/mpqemu-link.c
+++ b/io/mpqemu-link.c
@@ -10,6 +10,7 @@
#include "qemu/osdep.h"
#include "qemu-common.h"
+#include <poll.h>
#include "qemu/module.h"
#include "io/mpqemu-link.h"
@@ -204,6 +205,66 @@ int mpqemu_msg_recv(MPQemuMsg *msg, MPQemuChannel *chan)
return rc;
}
+/*
+ * wait_for_remote() Synchronizes QEMU and the remote process. The maximum
+ * wait time is 1s, after which the wait times out.
+ * The function alse returns a 64 bit return value after
+ * the wait. The function uses eventfd() to do the wait
+ * and pass the return values. eventfd() can't return a
+ * value of '0'. Therefore, all return values are offset
+ * by '1' at the sending end, and corrected at the
+ * receiving end.
+ */
+
+uint64_t wait_for_remote(int efd)
+{
+ struct pollfd pfd = { .fd = efd, .events = POLLIN };
+ uint64_t val;
+ int ret;
+
+ ret = poll(&pfd, 1, 1000);
+
+ switch (ret) {
+ case 0:
+ qemu_log_mask(LOG_REMOTE_DEBUG, "Error wait_for_remote: Timed out\n");
+ /* TODO: Kick-off error recovery */
+ return UINT64_MAX;
+ case -1:
+ qemu_log_mask(LOG_REMOTE_DEBUG, "Poll error wait_for_remote: %s\n",
+ strerror(errno));
+ return UINT64_MAX;
+ default:
+ if (read(efd, &val, sizeof(val)) == -1) {
+ qemu_log_mask(LOG_REMOTE_DEBUG, "Error wait_for_remote: %s\n",
+ strerror(errno));
+ return UINT64_MAX;
+ }
+ }
+
+ /*
+ * The remote process could write a non-zero value
+ * to the eventfd to wake QEMU up. However, the drawback of using eventfd
+ * for this purpose is that a return value of zero wouldn't wake QEMU up.
+ * Therefore, we offset the return value by one at the remote process and
+ * correct it in the QEMU end.
+ */
+ val = (val == UINT64_MAX) ? val : (val - 1);
+
+ return val;
+}
+
+void notify_proxy(int efd, uint64_t val)
+{
+ val = (val == UINT64_MAX) ? val : (val + 1);
+ ssize_t len = -1;
+
+ len = write(efd, &val, sizeof(val));
+ if (len == -1 || len != sizeof(val)) {
+ qemu_log_mask(LOG_REMOTE_DEBUG, "Error notify_proxy: %s\n",
+ strerror(errno));
+ }
+}
+
static gboolean mpqemu_link_handler_prepare(GSource *gsrc, gint *timeout)
{
g_assert(timeout);
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (11 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 10:31 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process elena.ufimtseva
` (25 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
PCI host bridge is setup for the remote device process. It is
implemented using remote-pcihost object. It is an extension of the PCI
host bridge setup by QEMU.
Remote-pcihost configures a PCI bus which could be used by the remote
PCI device to latch on to.
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 2 ++
hw/pci/Makefile.objs | 2 +-
include/remote/pcihost.h | 45 ++++++++++++++++++++++++++++
remote/Makefile.objs | 1 +
remote/pcihost.c | 64 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 113 insertions(+), 1 deletion(-)
create mode 100644 include/remote/pcihost.h
create mode 100644 remote/pcihost.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 93ad693da4..0cda5ee06a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2859,6 +2859,8 @@ F: remote/Makefile.objs
F: remote/remote-main.c
F: include/io/mpqemu-link.h
F: io/mpqemu-link.c
+F: include/remote/pcihost.h
+F: remote/pcihost.c
Build and test automation
-------------------------
diff --git a/hw/pci/Makefile.objs b/hw/pci/Makefile.objs
index 955be54472..90693a7695 100644
--- a/hw/pci/Makefile.objs
+++ b/hw/pci/Makefile.objs
@@ -13,6 +13,6 @@ common-obj-$(CONFIG_PCI_EXPRESS) += pcie_port.o pcie_host.o
common-obj-$(call lnot,$(CONFIG_PCI)) += pci-stub.o
common-obj-$(CONFIG_ALL) += pci-stub.o
-remote-pci-obj-$(CONFIG_MPQEMU) += pci.o pci_bridge.o
+remote-pci-obj-$(CONFIG_MPQEMU) += pci.o pci_bridge.o pci_host.o pcie_host.o
remote-pci-obj-$(CONFIG_MPQEMU) += msi.o msix.o
remote-pci-obj-$(CONFIG_MPQEMU) += pcie.o
diff --git a/include/remote/pcihost.h b/include/remote/pcihost.h
new file mode 100644
index 0000000000..7aca9ccaf1
--- /dev/null
+++ b/include/remote/pcihost.h
@@ -0,0 +1,45 @@
+/*
+ * PCI Host for remote device
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef REMOTE_PCIHOST_H
+#define REMOTE_PCIHOST_H
+
+#include <stddef.h>
+#include <stdint.h>
+
+#include "exec/memory.h"
+#include "hw/pci/pcie_host.h"
+
+#define TYPE_REMOTE_HOST_DEVICE "remote-pcihost"
+#define REMOTE_HOST_DEVICE(obj) \
+ OBJECT_CHECK(RemPCIHost, (obj), TYPE_REMOTE_HOST_DEVICE)
+
+typedef struct RemPCIHost {
+ /*< private >*/
+ PCIExpressHost parent_obj;
+ /*< public >*/
+
+ /*
+ * Memory Controller Hub (MCH) may not be necessary for the emulation
+ * program. The two important reasons for implementing a PCI host in the
+ * emulation program are:
+ * - Provide a PCI bus for IO devices
+ * - Enable translation of guest PA to the PCI bar regions
+ *
+ * For both the above mentioned purposes, it doesn't look like we would
+ * need the MCH
+ */
+
+ MemoryRegion *mr_pci_mem;
+ MemoryRegion *mr_sys_mem;
+ MemoryRegion *mr_sys_io;
+} RemPCIHost;
+
+#endif
diff --git a/remote/Makefile.objs b/remote/Makefile.objs
index a9b2256b2a..2757f5a265 100644
--- a/remote/Makefile.objs
+++ b/remote/Makefile.objs
@@ -1 +1,2 @@
remote-pci-obj-$(CONFIG_MPQEMU) += remote-main.o
+remote-pci-obj-$(CONFIG_MPQEMU) += pcihost.o
diff --git a/remote/pcihost.c b/remote/pcihost.c
new file mode 100644
index 0000000000..dbe081903e
--- /dev/null
+++ b/remote/pcihost.c
@@ -0,0 +1,64 @@
+/*
+ * Remote PCI host device
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include <sys/types.h>
+#include <unistd.h>
+
+#include "qemu/osdep.h"
+#include "hw/pci/pci.h"
+#include "hw/pci/pci_host.h"
+#include "hw/pci/pcie_host.h"
+#include "hw/qdev-properties.h"
+#include "remote/pcihost.h"
+#include "exec/memory.h"
+
+static const char *remote_host_root_bus_path(PCIHostState *host_bridge,
+ PCIBus *rootbus)
+{
+ return "0000:00";
+}
+
+static void remote_host_realize(DeviceState *dev, Error **errp)
+{
+ char *busname = g_strdup_printf("remote-pci-%ld", (unsigned long)getpid());
+ PCIHostState *pci = PCI_HOST_BRIDGE(dev);
+ RemPCIHost *s = REMOTE_HOST_DEVICE(dev);
+
+ pci->bus = pci_root_bus_new(DEVICE(s), busname,
+ s->mr_pci_mem, s->mr_sys_io,
+ 0, TYPE_PCIE_BUS);
+}
+
+static void remote_host_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(klass);
+
+ hc->root_bus_path = remote_host_root_bus_path;
+ dc->realize = remote_host_realize;
+
+ dc->user_creatable = false;
+ set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+ dc->fw_name = "pci";
+}
+
+static const TypeInfo remote_host_info = {
+ .name = TYPE_REMOTE_HOST_DEVICE,
+ .parent = TYPE_PCIE_HOST_BRIDGE,
+ .instance_size = sizeof(RemPCIHost),
+ .class_init = remote_host_class_init,
+};
+
+static void remote_machine_register(void)
+{
+ type_register_static(&remote_host_info);
+}
+
+type_init(remote_machine_register)
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (12 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 10:43 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device elena.ufimtseva
` (24 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
remote-machine object sets up various subsystems of the remote device
process. Instantiate PCI host bridge object and initialize RAM, IO &
PCI memory regions.
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 2 +
Makefile.objs | 1 +
exec.c | 3 +-
include/exec/address-spaces.h | 2 +
include/remote/machine.h | 30 +++++++++++++
remote/Makefile.objs | 2 +
remote/machine.c | 84 +++++++++++++++++++++++++++++++++++
remote/remote-main.c | 7 +++
util/Makefile.objs | 2 +
9 files changed, 131 insertions(+), 2 deletions(-)
create mode 100644 include/remote/machine.h
create mode 100644 remote/machine.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0cda5ee06a..09764e461c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2861,6 +2861,8 @@ F: include/io/mpqemu-link.h
F: io/mpqemu-link.c
F: include/remote/pcihost.h
F: remote/pcihost.c
+F: include/remote/machine.h
+F: remote/machine.c
Build and test automation
-------------------------
diff --git a/Makefile.objs b/Makefile.objs
index f6654633b4..ff3f06b146 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -31,6 +31,7 @@ remote-pci-obj-$(CONFIG_MPQEMU) += block/
remote-pci-obj-$(CONFIG_MPQEMU) += migration/
remote-pci-obj-$(CONFIG_MPQEMU) += remote/
remote-pci-obj-$(CONFIG_MPQEMU) += accel/
+remote-pci-obj-$(CONFIG_MPQEMU) += util/
remote-pci-obj-$(CONFIG_MPQEMU) += cpus-common.o
remote-pci-obj-$(CONFIG_MPQEMU) += dma-helpers.o
diff --git a/exec.c b/exec.c
index d0ac9545f4..5b1e414099 100644
--- a/exec.c
+++ b/exec.c
@@ -161,7 +161,6 @@ typedef struct subpage_t {
#define PHYS_SECTION_UNASSIGNED 0
static void io_mem_init(void);
-static void memory_map_init(void);
static void tcg_log_global_after_sync(MemoryListener *listener);
static void tcg_commit(MemoryListener *listener);
@@ -2963,7 +2962,7 @@ static void tcg_commit(MemoryListener *listener)
tlb_flush(cpuas->cpu);
}
-static void memory_map_init(void)
+void memory_map_init(void)
{
system_memory = g_malloc(sizeof(*system_memory));
diff --git a/include/exec/address-spaces.h b/include/exec/address-spaces.h
index db8bfa9a92..56a877b7ba 100644
--- a/include/exec/address-spaces.h
+++ b/include/exec/address-spaces.h
@@ -33,6 +33,8 @@ MemoryRegion *get_system_memory(void);
*/
MemoryRegion *get_system_io(void);
+void memory_map_init(void);
+
extern AddressSpace address_space_memory;
extern AddressSpace address_space_io;
diff --git a/include/remote/machine.h b/include/remote/machine.h
new file mode 100644
index 0000000000..7e9bdbe28e
--- /dev/null
+++ b/include/remote/machine.h
@@ -0,0 +1,30 @@
+/*
+ * Remote machine configuration
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef REMOTE_MACHINE_H
+#define REMOTE_MACHINE_H
+
+#include "qemu/osdep.h"
+#include "qom/object.h"
+#include "hw/boards.h"
+#include "remote/pcihost.h"
+#include "qemu/notify.h"
+
+typedef struct RemMachineState {
+ MachineState parent_obj;
+
+ RemPCIHost *host;
+} RemMachineState;
+
+#define TYPE_REMOTE_MACHINE "remote-machine"
+#define REMOTE_MACHINE(obj) \
+ OBJECT_CHECK(RemMachineState, (obj), TYPE_REMOTE_MACHINE)
+
+#endif
diff --git a/remote/Makefile.objs b/remote/Makefile.objs
index 2757f5a265..55f405d048 100644
--- a/remote/Makefile.objs
+++ b/remote/Makefile.objs
@@ -1,2 +1,4 @@
remote-pci-obj-$(CONFIG_MPQEMU) += remote-main.o
remote-pci-obj-$(CONFIG_MPQEMU) += pcihost.o
+remote-pci-obj-$(CONFIG_MPQEMU) += machine.o
+remote-pci-obj-$(CONFIG_MPQEMU) += ../util/machine-notify.o
diff --git a/remote/machine.c b/remote/machine.c
new file mode 100644
index 0000000000..97e4f194ea
--- /dev/null
+++ b/remote/machine.c
@@ -0,0 +1,84 @@
+/*
+ * Machine for remote device
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include <stdint.h>
+#include <sys/types.h>
+
+#include "qemu/osdep.h"
+#include "remote/pcihost.h"
+#include "remote/machine.h"
+#include "exec/address-spaces.h"
+#include "exec/memory.h"
+#include "exec/ioport.h"
+#include "qemu/thread.h"
+#include "qom/object.h"
+#include "qemu/module.h"
+#include "qapi/error.h"
+#include "qemu/main-loop.h"
+#include "qemu-common.h"
+#include "sysemu/sysemu.h"
+#include "qemu/notify.h"
+
+static void remote_machine_init(Object *obj)
+{
+ RemMachineState *s = REMOTE_MACHINE(obj);
+ RemPCIHost *rem_host;
+ MemoryRegion *system_memory, *system_io, *pci_memory;
+
+ Error *error_abort = NULL;
+
+ object_property_add_child(object_get_root(), "machine", obj, &error_abort);
+ if (error_abort) {
+ error_report_err(error_abort);
+ }
+
+ memory_map_init();
+
+ system_memory = get_system_memory();
+ system_io = get_system_io();
+
+ pci_memory = g_new(MemoryRegion, 1);
+ memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
+
+ rem_host = REMOTE_HOST_DEVICE(qdev_create(NULL, TYPE_REMOTE_HOST_DEVICE));
+
+ rem_host->mr_pci_mem = pci_memory;
+ rem_host->mr_sys_mem = system_memory;
+ rem_host->mr_sys_io = system_io;
+
+ s->host = rem_host;
+
+ object_property_add_child(OBJECT(s), "remote-device", OBJECT(rem_host),
+ &error_abort);
+ if (error_abort) {
+ error_report_err(error_abort);
+ return;
+ }
+
+ qemu_mutex_lock_iothread();
+ memory_region_add_subregion_overlap(system_memory, 0x0, pci_memory, -1);
+ qemu_mutex_unlock_iothread();
+
+ qdev_init_nofail(DEVICE(rem_host));
+}
+
+static const TypeInfo remote_machine = {
+ .name = TYPE_REMOTE_MACHINE,
+ .parent = TYPE_MACHINE,
+ .instance_size = sizeof(RemMachineState),
+ .instance_init = remote_machine_init,
+};
+
+static void remote_machine_register_types(void)
+{
+ type_register_static(&remote_machine);
+}
+
+type_init(remote_machine_register_types);
diff --git a/remote/remote-main.c b/remote/remote-main.c
index 7c0764ad01..ecf30e0cba 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -14,10 +14,17 @@
#include <stdio.h>
#include "qemu/module.h"
+#include "remote/pcihost.h"
+#include "remote/machine.h"
+#include "hw/boards.h"
+#include "hw/qdev-core.h"
+#include "qemu/main-loop.h"
int main(int argc, char *argv[])
{
module_call_init(MODULE_INIT_QOM);
+ current_machine = MACHINE(REMOTE_MACHINE(object_new(TYPE_REMOTE_MACHINE)));
+
return 0;
}
diff --git a/util/Makefile.objs b/util/Makefile.objs
index fe339c2636..d8f0061157 100644
--- a/util/Makefile.objs
+++ b/util/Makefile.objs
@@ -64,3 +64,5 @@ util-obj-$(CONFIG_GIO) += dbus.o
dbus.o-cflags = $(GIO_CFLAGS)
dbus.o-libs = $(GIO_LIBS)
util-obj-$(CONFIG_USER_ONLY) += selfmap.o
+
+remote-pci-obj-$(CONFIG_MPQEMU) += notify.o
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (13 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 12:11 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 16/36] multi-process: remote process initialization elena.ufimtseva
` (23 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
sync_sysmem_msg_t message format is defined. It is used to send
file descriptors of the RAM regions to remote device.
RAM on the remote device is configured with a set of file descriptors.
Old RAM regions are deleted and new regions, each with an fd, is
added to the RAM.
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 2 ++
Makefile.target | 2 ++
exec.c | 17 +++++++++++
include/exec/ram_addr.h | 2 ++
include/io/mpqemu-link.h | 12 ++++++++
include/remote/memory.h | 20 +++++++++++++
io/mpqemu-link.c | 13 +++++++++
remote/memory.c | 63 ++++++++++++++++++++++++++++++++++++++++
8 files changed, 131 insertions(+)
create mode 100644 include/remote/memory.h
create mode 100644 remote/memory.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 09764e461c..98237fff62 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2863,6 +2863,8 @@ F: include/remote/pcihost.h
F: remote/pcihost.c
F: include/remote/machine.h
F: remote/machine.c
+F: include/remote/memory.h
+F: remote/memory.c
Build and test automation
-------------------------
diff --git a/Makefile.target b/Makefile.target
index 70fa1eeca5..500fa07fda 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -143,6 +143,8 @@ remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/replay.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/xen-mapcache.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/audio.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/monitor.o
+
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += remote/memory.o
endif
#########################################################
diff --git a/exec.c b/exec.c
index 5b1e414099..1e02e00f00 100644
--- a/exec.c
+++ b/exec.c
@@ -2371,6 +2371,23 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
return block;
}
+
+void qemu_ram_init_from_fd(MemoryRegion *mr, int fd, uint64_t size,
+ ram_addr_t offset, Error **errp)
+{
+ char *name = g_strdup_printf("%d", fd);
+
+ memory_region_init(mr, NULL, name, size);
+ mr->ram = true;
+ mr->terminates = true;
+ mr->destructor = NULL;
+ mr->align = 0;
+ mr->ram_block = qemu_ram_alloc_from_fd(size, mr, RAM_SHARED, fd, offset,
+ errp);
+ mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
+
+ g_free(name);
+}
#endif
static
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 1b9f489ff0..d9d7314f51 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -122,6 +122,8 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
uint32_t ram_flags, int fd,
off_t offset, Error **errp);
+void qemu_ram_init_from_fd(MemoryRegion *mr, int fd, uint64_t size,
+ ram_addr_t offset, Error **errp);
RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
MemoryRegion *mr, Error **errp);
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index ef95599bca..d46cb81058 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -16,6 +16,8 @@
#include "qom/object.h"
#include "qemu/thread.h"
+#include "exec/cpu-common.h"
+#include "exec/hwaddr.h"
#define TYPE_MPQEMU_LINK "mpqemu-link"
#define MPQEMU_LINK(obj) \
@@ -27,15 +29,23 @@
/**
* mpqemu_cmd_t:
+ * SYNC_SYSMEM Shares QEMU's RAM with remote device's RAM
*
* proc_cmd_t enum type to specify the command to be executed on the remote
* device.
*/
typedef enum {
INIT = 0,
+ SYNC_SYSMEM,
MAX,
} mpqemu_cmd_t;
+typedef struct {
+ hwaddr gpas[REMOTE_MAX_FDS];
+ uint64_t sizes[REMOTE_MAX_FDS];
+ ram_addr_t offsets[REMOTE_MAX_FDS];
+} sync_sysmem_msg_t;
+
/**
* MPQemuMsg:
* @cmd: The remote command
@@ -49,6 +59,7 @@ typedef enum {
* MPQemuMsg Format of the message sent to the remote device from QEMU.
*
*/
+
typedef struct {
mpqemu_cmd_t cmd;
int bytestream;
@@ -56,6 +67,7 @@ typedef struct {
union {
uint64_t u64;
+ sync_sysmem_msg_t sync_sysmem;
} data1;
int fds[REMOTE_MAX_FDS];
diff --git a/include/remote/memory.h b/include/remote/memory.h
new file mode 100644
index 0000000000..e2e479bb6f
--- /dev/null
+++ b/include/remote/memory.h
@@ -0,0 +1,20 @@
+/*
+ * Memory manager for remote device
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef REMOTE_MEMORY_H
+#define REMOTE_MEMORY_H
+
+#include "qemu/osdep.h"
+#include "exec/hwaddr.h"
+#include "io/mpqemu-link.h"
+
+void remote_sysmem_reconfig(MPQemuMsg *msg, Error **errp);
+
+#endif
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
index cc0a7aecd4..3f81cef96e 100644
--- a/io/mpqemu-link.c
+++ b/io/mpqemu-link.c
@@ -368,6 +368,19 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
}
}
}
+ /* Verify message specific fields. */
+ switch (msg->cmd) {
+ case SYNC_SYSMEM:
+ if (msg->num_fds == 0 || msg->bytestream != 0) {
+ return false;
+ }
+ if (msg->size != sizeof(msg->data1)) {
+ return false;
+ }
+ break;
+ default:
+ break;
+ }
return true;
}
diff --git a/remote/memory.c b/remote/memory.c
new file mode 100644
index 0000000000..2c8b7bb42f
--- /dev/null
+++ b/remote/memory.c
@@ -0,0 +1,63 @@
+/*
+ * Memory manager for remote device
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include <stdint.h>
+#include <sys/types.h>
+
+#include "qemu/osdep.h"
+#include "qemu/queue.h"
+#include "qemu-common.h"
+#include "remote/memory.h"
+#include "exec/memory.h"
+#include "exec/address-spaces.h"
+#include "cpu.h"
+#include "exec/ram_addr.h"
+#include "io/mpqemu-link.h"
+#include "qemu/main-loop.h"
+#include "qapi/error.h"
+
+void remote_sysmem_reconfig(MPQemuMsg *msg, Error **errp)
+{
+ sync_sysmem_msg_t *sysmem_info = &msg->data1.sync_sysmem;
+ MemoryRegion *sysmem, *subregion, *next;
+ Error *local_err = NULL;
+ int region;
+
+ sysmem = get_system_memory();
+
+ qemu_mutex_lock_iothread();
+
+ memory_region_transaction_begin();
+
+ QTAILQ_FOREACH_SAFE(subregion, &sysmem->subregions, subregions_link, next) {
+ if (subregion->ram) {
+ memory_region_del_subregion(sysmem, subregion);
+ qemu_ram_free(subregion->ram_block);
+ }
+ }
+
+ for (region = 0; region < msg->num_fds; region++) {
+ subregion = g_new(MemoryRegion, 1);
+ qemu_ram_init_from_fd(subregion, msg->fds[region],
+ sysmem_info->sizes[region],
+ sysmem_info->offsets[region], &local_err);
+ if (local_err) {
+ error_propagate(errp, local_err);
+ break;
+ }
+
+ memory_region_add_subregion(sysmem, sysmem_info->gpas[region],
+ subregion);
+ }
+
+ memory_region_transaction_commit();
+
+ qemu_mutex_unlock_iothread();
+}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 16/36] multi-process: remote process initialization
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (14 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 17/36] multi-process: introduce proxy object elena.ufimtseva
` (22 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Adds the handler to process message from QEMU,
Initialize remote process main loop, handles SYNC_SYSMEM
message by updating its "system_memory" container using
shared file descriptors received from QEMU.
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
MAINTAINERS | 1 +
remote/remote-common.h | 21 +++++++++
remote/remote-main.c | 104 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 126 insertions(+)
create mode 100644 remote/remote-common.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 98237fff62..96f8d7ff19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2857,6 +2857,7 @@ M: John G Johnson <john.g.johnson@oracle.com>
S: Maintained
F: remote/Makefile.objs
F: remote/remote-main.c
+F: remote/remote-common.h
F: include/io/mpqemu-link.h
F: io/mpqemu-link.c
F: include/remote/pcihost.h
diff --git a/remote/remote-common.h b/remote/remote-common.h
new file mode 100644
index 0000000000..12c8d066cf
--- /dev/null
+++ b/remote/remote-common.h
@@ -0,0 +1,21 @@
+/*
+ * Remote device initialization
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+#ifndef REMOTE_COMMON_H
+#define REMOTE_COMMON_H
+
+extern const char *__progname;
+
+#define PROC_INFO_LENGTH 1024
+gchar *print_pid_exec(gchar *str);
+
+#endif /* REMOTE_COMMON_H */
+
+
+
diff --git a/remote/remote-main.c b/remote/remote-main.c
index ecf30e0cba..dbd6ad2529 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -12,6 +12,7 @@
#include "qemu-common.h"
#include <stdio.h>
+#include <unistd.h>
#include "qemu/module.h"
#include "remote/pcihost.h"
@@ -19,12 +20,115 @@
#include "hw/boards.h"
#include "hw/qdev-core.h"
#include "qemu/main-loop.h"
+#include "remote/memory.h"
+#include "io/mpqemu-link.h"
+#include "qapi/error.h"
+#include "qemu/main-loop.h"
+#include "sysemu/cpus.h"
+#include "qemu-common.h"
+#include "hw/pci/pci.h"
+#include "qemu/thread.h"
+#include "qemu/main-loop.h"
+#include "qemu/config-file.h"
+#include "sysemu/sysemu.h"
+#include "block/block.h"
+#include "exec/ramlist.h"
+#include "remote/remote-common.h"
+
+static MPQemuLinkState *mpqemu_link;
+
+gchar *print_pid_exec(gchar *str)
+{
+ if (!str) {
+ return NULL;
+ }
+ memset(str, 0, PROC_INFO_LENGTH);
+ g_snprintf(str, PROC_INFO_LENGTH, "pid %d, exec name %s ",
+ getpid(), __progname);
+ return str;
+}
+
+static void process_msg(GIOCondition cond, MPQemuLinkState *link,
+ MPQemuChannel *chan)
+{
+ MPQemuMsg *msg = NULL;
+ Error *err = NULL;
+ g_autofree gchar *pid_exec = NULL;
+
+ pid_exec = g_malloc(PROC_INFO_LENGTH);
+
+ if ((cond & G_IO_HUP) || (cond & G_IO_ERR)) {
+ goto finalize_loop;
+ }
+
+ msg = g_malloc0(sizeof(MPQemuMsg));
+
+ if (mpqemu_msg_recv(msg, chan) < 0) {
+ error_setg(&err, "Failed to receive message in remote process %s",
+ print_pid_exec(pid_exec));
+ goto finalize_loop;
+ }
+
+ switch (msg->cmd) {
+ case INIT:
+ break;
+ default:
+ error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
+ goto finalize_loop;
+ }
+
+ g_free(msg->data2);
+ g_free(msg);
+
+ return;
+
+finalize_loop:
+ if (err) {
+ error_report_err(err);
+ }
+ g_free(msg);
+ mpqemu_link_finalize(mpqemu_link);
+ mpqemu_link = NULL;
+}
int main(int argc, char *argv[])
{
+ Error *err = NULL;
+
module_call_init(MODULE_INIT_QOM);
+ bdrv_init_with_whitelist();
+
+ if (qemu_init_main_loop(&err)) {
+ error_report_err(err);
+ return -EBUSY;
+ }
+
+ qemu_init_cpu_loop();
+
+ page_size_init();
+
+ qemu_mutex_init(&ram_list.mutex);
+
current_machine = MACHINE(REMOTE_MACHINE(object_new(TYPE_REMOTE_MACHINE)));
+ mpqemu_link = mpqemu_link_create();
+ if (!mpqemu_link) {
+ printf("Could not create MPQemu link pid %d, exec_name %s",
+ getpid(), __progname);
+ return -1;
+ }
+
+ mpqemu_init_channel(mpqemu_link, &mpqemu_link->com, STDIN_FILENO);
+
+ mpqemu_link_set_callback(mpqemu_link, process_msg);
+
+ qdev_machine_creation_done();
+ qemu_mutex_lock_iothread();
+ qemu_run_machine_init_done_notifiers();
+ qemu_mutex_unlock_iothread();
+
+ mpqemu_start_coms(mpqemu_link, mpqemu_link->com);
+
return 0;
}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 17/36] multi-process: introduce proxy object
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (15 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 16/36] multi-process: remote process initialization elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 12:23 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel elena.ufimtseva
` (21 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Defines a PCI Device proxy object as a parent of TYPE_PCI_DEVICE.
PCI Proxy Object registers as a PCI device with QEMU and forwards all
PCI accesses to the remote process using the communication channel.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
MAINTAINERS | 3 ++
hw/Makefile.objs | 2 ++
hw/proxy/Makefile.objs | 1 +
hw/proxy/qemu-proxy.c | 56 +++++++++++++++++++++++++++++++++++
include/hw/proxy/qemu-proxy.h | 46 ++++++++++++++++++++++++++++
include/io/mpqemu-link.h | 1 +
6 files changed, 109 insertions(+)
create mode 100644 hw/proxy/Makefile.objs
create mode 100644 hw/proxy/qemu-proxy.c
create mode 100644 include/hw/proxy/qemu-proxy.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 96f8d7ff19..3da3dcd311 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2866,6 +2866,9 @@ F: include/remote/machine.h
F: remote/machine.c
F: include/remote/memory.h
F: remote/memory.c
+F: hw/proxy/Makefile.objs
+F: hw/proxy/qemu-proxy.c
+F: include/hw/proxy/qemu-proxy.h
Build and test automation
-------------------------
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index af9235b6f2..7b489b12a5 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -45,6 +45,8 @@ endif
common-obj-y += $(devices-dirs-y)
obj-y += $(devices-dirs-y)
+common-obj-$(CONFIG_MPQEMU) += proxy/
+
remote-pci-obj-$(CONFIG_MPQEMU) += core/
remote-pci-obj-$(CONFIG_MPQEMU) += block/
remote-pci-obj-$(CONFIG_MPQEMU) += pci/
diff --git a/hw/proxy/Makefile.objs b/hw/proxy/Makefile.objs
new file mode 100644
index 0000000000..eb81624cf8
--- /dev/null
+++ b/hw/proxy/Makefile.objs
@@ -0,0 +1 @@
+common-obj-$(CONFIG_MPQEMU) += qemu-proxy.o
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
new file mode 100644
index 0000000000..bf6c4117ef
--- /dev/null
+++ b/hw/proxy/qemu-proxy.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "qapi/error.h"
+#include "io/mpqemu-link.h"
+#include "hw/proxy/qemu-proxy.h"
+#include "hw/pci/pci.h"
+
+static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
+{
+ PCIProxyDev *dev = PCI_PROXY_DEV(device);
+ PCIProxyDevClass *k = PCI_PROXY_DEV_GET_CLASS(dev);
+ Error *local_err = NULL;
+
+ if (k->realize) {
+ k->realize(dev, &local_err);
+ if (local_err) {
+ error_propagate(errp, local_err);
+ }
+ }
+}
+
+static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
+{
+ PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+ k->realize = pci_proxy_dev_realize;
+}
+
+static const TypeInfo pci_proxy_dev_type_info = {
+ .name = TYPE_PCI_PROXY_DEV,
+ .parent = TYPE_PCI_DEVICE,
+ .instance_size = sizeof(PCIProxyDev),
+ .class_size = sizeof(PCIProxyDevClass),
+ .class_init = pci_proxy_dev_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_CONVENTIONAL_PCI_DEVICE },
+ { },
+ },
+};
+
+static void pci_proxy_dev_register_types(void)
+{
+ type_register_static(&pci_proxy_dev_type_info);
+}
+
+type_init(pci_proxy_dev_register_types)
+
diff --git a/include/hw/proxy/qemu-proxy.h b/include/hw/proxy/qemu-proxy.h
new file mode 100644
index 0000000000..d7eaf26f29
--- /dev/null
+++ b/include/hw/proxy/qemu-proxy.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_PROXY_H
+#define QEMU_PROXY_H
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "io/mpqemu-link.h"
+#include "hw/pci/pci.h"
+
+#define TYPE_PCI_PROXY_DEV "pci-proxy-dev"
+
+#define PCI_PROXY_DEV(obj) \
+ OBJECT_CHECK(PCIProxyDev, (obj), TYPE_PCI_PROXY_DEV)
+
+#define PCI_PROXY_DEV_CLASS(klass) \
+ OBJECT_CLASS_CHECK(PCIProxyDevClass, (klass), TYPE_PCI_PROXY_DEV)
+
+#define PCI_PROXY_DEV_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(PCIProxyDevClass, (obj), TYPE_PCI_PROXY_DEV)
+
+typedef struct PCIProxyDev {
+ PCIDevice parent_dev;
+
+ MPQemuLinkState *mpqemu_link;
+
+ int socket;
+
+} PCIProxyDev;
+
+typedef struct PCIProxyDevClass {
+ PCIDeviceClass parent_class;
+
+ void (*realize)(PCIProxyDev *dev, Error **errp);
+
+ char *command;
+} PCIProxyDevClass;
+
+#endif /* QEMU_PROXY_H */
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index d46cb81058..73cc59b874 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -14,6 +14,7 @@
#include "qemu/osdep.h"
#include "qemu-common.h"
+#include "sys/eventfd.h"
#include "qom/object.h"
#include "qemu/thread.h"
#include "exec/cpu-common.h"
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (16 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 17/36] multi-process: introduce proxy object elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 12:35 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process elena.ufimtseva
` (20 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Add "socket" object property which initializes the communication channel
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
hw/proxy/qemu-proxy.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index bf6c4117ef..40bf56fd37 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -14,6 +14,25 @@
#include "hw/proxy/qemu-proxy.h"
#include "hw/pci/pci.h"
+static void proxy_set_socket(Object *obj, const char *str, Error **errp)
+{
+ PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
+
+ pdev->socket = atoi(str);
+
+ mpqemu_init_channel(pdev->mpqemu_link, &pdev->mpqemu_link->com,
+ pdev->socket);
+}
+
+static void proxy_init(Object *obj)
+{
+ PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
+
+ pdev->mpqemu_link = mpqemu_link_create();
+
+ object_property_add_str(obj, "socket", NULL, proxy_set_socket, NULL);
+}
+
static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
{
PCIProxyDev *dev = PCI_PROXY_DEV(device);
@@ -41,6 +60,7 @@ static const TypeInfo pci_proxy_dev_type_info = {
.instance_size = sizeof(PCIProxyDev),
.class_size = sizeof(PCIProxyDevClass),
.class_init = pci_proxy_dev_class_init,
+ .instance_init = proxy_init,
.interfaces = (InterfaceInfo[]) {
{ INTERFACE_CONVENTIONAL_PCI_DEVICE },
{ },
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (17 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 12:54 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to " elena.ufimtseva
` (19 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Send a message to the remote process to connect PCI device with the
corresponding Proxy object in QEMU
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
hw/proxy/qemu-proxy.c | 34 +++++++++++++++++++++++++++++++
include/io/mpqemu-link.h | 5 +++++
io/mpqemu-link.c | 3 +++
remote/remote-main.c | 43 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 85 insertions(+)
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index 40bf56fd37..9b5e429a88 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -17,11 +17,45 @@
static void proxy_set_socket(Object *obj, const char *str, Error **errp)
{
PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
+ DeviceState *dev = DEVICE(obj);
+ MPQemuMsg msg = { 0 };
+ int wait, fd[2];
pdev->socket = atoi(str);
mpqemu_init_channel(pdev->mpqemu_link, &pdev->mpqemu_link->com,
pdev->socket);
+
+ if (socketpair(AF_UNIX, SOCK_STREAM, 0, fd)) {
+ error_setg(errp, "Failed to create socket for device channel");
+ return;
+ }
+
+ wait = GET_REMOTE_WAIT;
+
+ msg.cmd = CONNECT_DEV;
+ msg.bytestream = 1;
+ msg.data2 = (uint8_t *)g_strdup(dev->id);
+ msg.size = sizeof(msg.data2);
+ msg.num_fds = 2;
+ msg.fds[0] = wait;
+ msg.fds[1] = fd[1];
+
+ mpqemu_msg_send(&msg, pdev->mpqemu_link->com);
+
+ if (wait_for_remote(wait)) {
+ error_setg(errp, "Failed to connect device to the remote");
+ close(fd[0]);
+ } else {
+ mpqemu_init_channel(pdev->mpqemu_link, &pdev->mpqemu_link->dev,
+ fd[0]);
+ }
+
+ PUT_REMOTE_WAIT(wait);
+
+ close(fd[1]);
+
+ g_free(msg.data2);
}
static void proxy_init(Object *obj)
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index 73cc59b874..ebae9afc45 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -38,6 +38,7 @@
typedef enum {
INIT = 0,
SYNC_SYSMEM,
+ CONNECT_DEV,
MAX,
} mpqemu_cmd_t;
@@ -120,8 +121,12 @@ struct MPQemuLinkState {
GMainLoop *loop;
MPQemuChannel *com;
+ MPQemuChannel *dev;
mpqemu_link_callback callback;
+
+ void *opaque;
+ QemuThread thread;
};
MPQemuLinkState *mpqemu_link_create(void);
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
index 3f81cef96e..f780b65181 100644
--- a/io/mpqemu-link.c
+++ b/io/mpqemu-link.c
@@ -46,6 +46,9 @@ MPQemuLinkState *mpqemu_link_create(void)
MPQemuLinkState *link = MPQEMU_LINK(object_new(TYPE_MPQEMU_LINK));
link->com = NULL;
+ link->dev = NULL;
+
+ link->opaque = NULL;
return link;
}
diff --git a/remote/remote-main.c b/remote/remote-main.c
index dbd6ad2529..f541baae6a 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -35,6 +35,9 @@
#include "exec/ramlist.h"
#include "remote/remote-common.h"
+static void process_msg(GIOCondition cond, MPQemuLinkState *link,
+ MPQemuChannel *chan);
+
static MPQemuLinkState *mpqemu_link;
gchar *print_pid_exec(gchar *str)
@@ -48,6 +51,43 @@ gchar *print_pid_exec(gchar *str)
return str;
}
+#define LINK_TO_DEV(link) ((PCIDevice *)link->opaque)
+
+static gpointer dev_thread(gpointer data)
+{
+ MPQemuLinkState *link = data;
+
+ mpqemu_start_coms(link, link->dev);
+
+ return NULL;
+}
+
+static void process_connect_dev_msg(MPQemuMsg *msg)
+{
+ char *devid = (char *)msg->data2;
+ MPQemuLinkState *link = NULL;
+ DeviceState *dev = NULL;
+ int wait = msg->fds[0];
+ int ret = 0;
+
+ dev = qdev_find_recursive(sysbus_get_default(), devid);
+ if (!dev) {
+ ret = 0xff;
+ goto exit;
+ }
+
+ link = mpqemu_link_create();
+ link->opaque = (void *)PCI_DEVICE(dev);
+
+ mpqemu_init_channel(link, &link->dev, msg->fds[1]);
+ mpqemu_link_set_callback(link, process_msg);
+ qemu_thread_create(&link->thread, "dev_thread", dev_thread, link,
+ QEMU_THREAD_JOINABLE);
+
+exit:
+ notify_proxy(wait, ret);
+}
+
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan)
{
@@ -72,6 +112,9 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
switch (msg->cmd) {
case INIT:
break;
+ case CONNECT_DEV:
+ process_connect_dev_msg(msg);
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to the remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (18 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 13:50 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints elena.ufimtseva
` (18 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
The Proxy Object sends the PCI config space accesses as messages
to the remote process over the communication channel
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
hw/proxy/qemu-proxy.c | 61 ++++++++++++++++++++++++++++++++++++++++
include/io/mpqemu-link.h | 8 ++++++
io/mpqemu-link.c | 6 ++++
remote/remote-main.c | 32 +++++++++++++++++++++
4 files changed, 107 insertions(+)
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index 9b5e429a88..87cf39c672 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -14,6 +14,65 @@
#include "hw/proxy/qemu-proxy.h"
#include "hw/pci/pci.h"
+static int config_op_send(PCIProxyDev *dev, uint32_t addr, uint32_t *val, int l,
+ unsigned int op)
+{
+ MPQemuMsg msg;
+ struct conf_data_msg conf_data;
+ int wait;
+
+ memset(&msg, 0, sizeof(MPQemuMsg));
+ conf_data.addr = addr;
+ conf_data.val = (op == PCI_CONFIG_WRITE) ? *val : 0;
+ conf_data.l = l;
+
+ msg.data2 = (uint8_t *)&conf_data;
+ if (!msg.data2) {
+ return -ENOMEM;
+ }
+
+ msg.size = sizeof(conf_data);
+ msg.cmd = op;
+ msg.bytestream = 1;
+
+ if (op == PCI_CONFIG_WRITE) {
+ msg.num_fds = 0;
+ } else {
+ /* TODO: Dont create fd each time for send. */
+ wait = GET_REMOTE_WAIT;
+ msg.num_fds = 1;
+ msg.fds[0] = wait;
+ }
+
+ mpqemu_msg_send(&msg, dev->mpqemu_link->dev);
+
+ if (op == PCI_CONFIG_READ) {
+ *val = (uint32_t)wait_for_remote(wait);
+ PUT_REMOTE_WAIT(wait);
+ }
+
+ return 0;
+}
+
+static uint32_t pci_proxy_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+ uint32_t val;
+
+ (void)pci_default_read_config(d, addr, len);
+
+ config_op_send(PCI_PROXY_DEV(d), addr, &val, len, PCI_CONFIG_READ);
+
+ return val;
+}
+
+static void pci_proxy_write_config(PCIDevice *d, uint32_t addr, uint32_t val,
+ int l)
+{
+ pci_default_write_config(d, addr, val, l);
+
+ config_op_send(PCI_PROXY_DEV(d), addr, &val, l, PCI_CONFIG_WRITE);
+}
+
static void proxy_set_socket(Object *obj, const char *str, Error **errp)
{
PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
@@ -86,6 +145,8 @@ static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
k->realize = pci_proxy_dev_realize;
+ k->config_read = pci_proxy_read_config;
+ k->config_write = pci_proxy_write_config;
}
static const TypeInfo pci_proxy_dev_type_info = {
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index ebae9afc45..7228a1915e 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -39,9 +39,17 @@ typedef enum {
INIT = 0,
SYNC_SYSMEM,
CONNECT_DEV,
+ PCI_CONFIG_WRITE,
+ PCI_CONFIG_READ,
MAX,
} mpqemu_cmd_t;
+struct conf_data_msg {
+ uint32_t addr;
+ uint32_t val;
+ int l;
+};
+
typedef struct {
hwaddr gpas[REMOTE_MAX_FDS];
uint64_t sizes[REMOTE_MAX_FDS];
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
index f780b65181..ef4a07b81a 100644
--- a/io/mpqemu-link.c
+++ b/io/mpqemu-link.c
@@ -381,6 +381,12 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
return false;
}
break;
+ case PCI_CONFIG_WRITE:
+ case PCI_CONFIG_READ:
+ if (msg->size != sizeof(struct conf_data_msg)) {
+ return false;
+ }
+ break;
default:
break;
}
diff --git a/remote/remote-main.c b/remote/remote-main.c
index f541baae6a..834574e172 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -53,6 +53,32 @@ gchar *print_pid_exec(gchar *str)
#define LINK_TO_DEV(link) ((PCIDevice *)link->opaque)
+static void process_config_write(PCIDevice *dev, MPQemuMsg *msg)
+{
+ struct conf_data_msg *conf = (struct conf_data_msg *)msg->data2;
+
+ qemu_mutex_lock_iothread();
+ pci_default_write_config(dev, conf->addr, conf->val, conf->l);
+ qemu_mutex_unlock_iothread();
+}
+
+static void process_config_read(PCIDevice *dev, MPQemuMsg *msg)
+{
+ struct conf_data_msg *conf = (struct conf_data_msg *)msg->data2;
+ uint32_t val;
+ int wait;
+
+ wait = msg->fds[0];
+
+ qemu_mutex_lock_iothread();
+ val = pci_default_read_config(dev, conf->addr, conf->l);
+ qemu_mutex_unlock_iothread();
+
+ notify_proxy(wait, val);
+
+ PUT_REMOTE_WAIT(wait);
+}
+
static gpointer dev_thread(gpointer data)
{
MPQemuLinkState *link = data;
@@ -115,6 +141,12 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
case CONNECT_DEV:
process_connect_dev_msg(msg);
break;
+ case PCI_CONFIG_WRITE:
+ process_config_write(LINK_TO_DEV(link), msg);
+ break;
+ case PCI_CONFIG_READ:
+ process_config_read(LINK_TO_DEV(link), msg);
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (19 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to " elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 14:19 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory elena.ufimtseva
` (17 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Proxy device object implements handler for PCI BAR writes and reads.
The handler uses BAR_WRITE/BAR_READ message to communicate to the
remote process with the BAR address and value to be written/read.
The remote process implements handler for BAR_WRITE/BAR_READ
message.
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
hw/proxy/qemu-proxy.c | 64 ++++++++++++++++++++++++++
include/hw/proxy/qemu-proxy.h | 20 ++++++++-
include/io/mpqemu-link.h | 12 +++++
io/mpqemu-link.c | 6 +++
remote/remote-main.c | 84 +++++++++++++++++++++++++++++++++++
5 files changed, 184 insertions(+), 2 deletions(-)
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index 87cf39c672..7fd0a312a5 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -169,3 +169,67 @@ static void pci_proxy_dev_register_types(void)
type_init(pci_proxy_dev_register_types)
+static void send_bar_access_msg(PCIProxyDev *dev, MemoryRegion *mr,
+ bool write, hwaddr addr, uint64_t *val,
+ unsigned size, bool memory)
+{
+ MPQemuLinkState *mpqemu_link = dev->mpqemu_link;
+ MPQemuMsg msg;
+ int wait;
+
+ memset(&msg, 0, sizeof(MPQemuMsg));
+
+ msg.bytestream = 0;
+ msg.size = sizeof(msg.data1);
+ msg.data1.bar_access.addr = mr->addr + addr;
+ msg.data1.bar_access.size = size;
+ msg.data1.bar_access.memory = memory;
+
+ if (write) {
+ msg.cmd = BAR_WRITE;
+ msg.data1.bar_access.val = *val;
+ } else {
+ wait = GET_REMOTE_WAIT;
+
+ msg.cmd = BAR_READ;
+ msg.num_fds = 1;
+ msg.fds[0] = wait;
+ }
+
+ mpqemu_msg_send(&msg, mpqemu_link->dev);
+
+ if (!write) {
+ *val = wait_for_remote(wait);
+ PUT_REMOTE_WAIT(wait);
+ }
+}
+
+void proxy_default_bar_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned size)
+{
+ ProxyMemoryRegion *pmr = opaque;
+
+ send_bar_access_msg(pmr->dev, &pmr->mr, true, addr, &val, size,
+ pmr->memory);
+}
+
+uint64_t proxy_default_bar_read(void *opaque, hwaddr addr, unsigned size)
+{
+ ProxyMemoryRegion *pmr = opaque;
+ uint64_t val;
+
+ send_bar_access_msg(pmr->dev, &pmr->mr, false, addr, &val, size,
+ pmr->memory);
+
+ return val;
+}
+
+const MemoryRegionOps proxy_default_ops = {
+ .read = proxy_default_bar_read,
+ .write = proxy_default_bar_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .impl = {
+ .min_access_size = 1,
+ .max_access_size = 1,
+ },
+};
diff --git a/include/hw/proxy/qemu-proxy.h b/include/hw/proxy/qemu-proxy.h
index d7eaf26f29..9e4127eccb 100644
--- a/include/hw/proxy/qemu-proxy.h
+++ b/include/hw/proxy/qemu-proxy.h
@@ -26,14 +26,25 @@
#define PCI_PROXY_DEV_GET_CLASS(obj) \
OBJECT_GET_CLASS(PCIProxyDevClass, (obj), TYPE_PCI_PROXY_DEV)
-typedef struct PCIProxyDev {
+typedef struct PCIProxyDev PCIProxyDev;
+
+typedef struct ProxyMemoryRegion {
+ PCIProxyDev *dev;
+ MemoryRegion mr;
+ bool memory;
+ bool present;
+ uint8_t type;
+} ProxyMemoryRegion;
+
+struct PCIProxyDev {
PCIDevice parent_dev;
MPQemuLinkState *mpqemu_link;
int socket;
-} PCIProxyDev;
+ ProxyMemoryRegion region[PCI_NUM_REGIONS];
+};
typedef struct PCIProxyDevClass {
PCIDeviceClass parent_class;
@@ -43,4 +54,9 @@ typedef struct PCIProxyDevClass {
char *command;
} PCIProxyDevClass;
+void proxy_default_bar_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned size);
+
+uint64_t proxy_default_bar_read(void *opaque, hwaddr addr, unsigned size);
+
#endif /* QEMU_PROXY_H */
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index 7228a1915e..41cf092f9e 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -31,6 +31,8 @@
/**
* mpqemu_cmd_t:
* SYNC_SYSMEM Shares QEMU's RAM with remote device's RAM
+ * BAR_WRITE Writes to PCI BAR region
+ * BAR_READ Reads from PCI BAR region
*
* proc_cmd_t enum type to specify the command to be executed on the remote
* device.
@@ -41,6 +43,8 @@ typedef enum {
CONNECT_DEV,
PCI_CONFIG_WRITE,
PCI_CONFIG_READ,
+ BAR_WRITE,
+ BAR_READ,
MAX,
} mpqemu_cmd_t;
@@ -56,6 +60,13 @@ typedef struct {
ram_addr_t offsets[REMOTE_MAX_FDS];
} sync_sysmem_msg_t;
+typedef struct {
+ hwaddr addr;
+ uint64_t val;
+ unsigned size;
+ bool memory;
+} bar_access_msg_t;
+
/**
* MPQemuMsg:
* @cmd: The remote command
@@ -78,6 +89,7 @@ typedef struct {
union {
uint64_t u64;
sync_sysmem_msg_t sync_sysmem;
+ bar_access_msg_t bar_access;
} data1;
int fds[REMOTE_MAX_FDS];
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
index ef4a07b81a..5cb93fc47b 100644
--- a/io/mpqemu-link.c
+++ b/io/mpqemu-link.c
@@ -387,6 +387,12 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
return false;
}
break;
+ case BAR_WRITE:
+ case BAR_READ:
+ if (msg->size != sizeof(msg->data1)) {
+ return false;
+ }
+ break;
default:
break;
}
diff --git a/remote/remote-main.c b/remote/remote-main.c
index 834574e172..0990509f7a 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -34,6 +34,7 @@
#include "block/block.h"
#include "exec/ramlist.h"
#include "remote/remote-common.h"
+#include "exec/memattrs.h"
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan);
@@ -114,6 +115,77 @@ exit:
notify_proxy(wait, ret);
}
+/* TODO: confirm memtx attrs. */
+static void process_bar_write(MPQemuMsg *msg, Error **errp)
+{
+ bar_access_msg_t *bar_access = &msg->data1.bar_access;
+ AddressSpace *as =
+ bar_access->memory ? &address_space_memory : &address_space_io;
+ MemTxResult res;
+
+ assert(is_power_of_2(bar_access->size) &&
+ bar_access->size <= sizeof(uint64_t));
+
+ res = address_space_rw(as, bar_access->addr, MEMTXATTRS_UNSPECIFIED,
+ (uint8_t *)&bar_access->val, bar_access->size,
+ true);
+
+ if (res != MEMTX_OK) {
+ error_setg(errp, "Could not perform address space write operation,"
+ " inaccessible address: %lx in pid %d, %s.",
+ bar_access->addr, getpid(), __progname);
+ }
+}
+
+static void process_bar_read(MPQemuMsg *msg, Error **errp)
+{
+ bar_access_msg_t *bar_access = &msg->data1.bar_access;
+ AddressSpace *as;
+ int wait = msg->fds[0];
+ MemTxResult res;
+ uint64_t val = 0;
+
+ as = bar_access->memory ? &address_space_memory : &address_space_io;
+
+ assert(is_power_of_2(bar_access->size) &&
+ bar_access->size <= sizeof(uint64_t));
+
+ res = address_space_rw(as, bar_access->addr, MEMTXATTRS_UNSPECIFIED,
+ (uint8_t *)&val, bar_access->size, false);
+
+ if (res != MEMTX_OK) {
+ error_setg(errp, "Could not perform address space read operation,"
+ " inaccessible address: %lx in pid %d, %s.",
+ bar_access->addr, getpid(), __progname);
+ val = (uint64_t)-1;
+ goto fail;
+ }
+
+ switch (bar_access->size) {
+ case 8:
+ /* Nothing to do as val is already 8 bytes long */
+ break;
+ case 4:
+ val = *((uint32_t *)&val);
+ break;
+ case 2:
+ val = *((uint16_t *)&val);
+ break;
+ case 1:
+ val = *((uint8_t *)&val);
+ break;
+ default:
+ error_setg(errp, "Invalid PCI BAR read size in pid %d, %s",
+ getpid(), __progname);
+ return;
+ }
+
+fail:
+ notify_proxy(wait, val);
+
+ PUT_REMOTE_WAIT(wait);
+}
+
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan)
{
@@ -147,6 +219,18 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
case PCI_CONFIG_READ:
process_config_read(LINK_TO_DEV(link), msg);
break;
+ case BAR_WRITE:
+ process_bar_write(msg, &err);
+ if (err) {
+ goto finalize_loop;
+ }
+ break;
+ case BAR_READ:
+ process_bar_read(msg, &err);
+ if (err) {
+ goto finalize_loop;
+ }
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (20 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 15:07 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq elena.ufimtseva
` (16 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Add memory-listener object which is used to keep the view of the RAM
in sync between QEMU and remote process.
A MemoryListener is registered for system-memory AddressSpace. The
listener sends SYNC_SYSMEM message to the remote process when memory
listener commits the changes to memory, the remote process receives
the message and processes it in the handler for SYNC_SYSMEM message.
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 2 +
Makefile.target | 3 +
hw/proxy/memory-sync.c | 217 +++++++++++++++++++++++++++++++++
hw/proxy/qemu-proxy.c | 6 +
include/hw/proxy/memory-sync.h | 37 ++++++
include/hw/proxy/qemu-proxy.h | 6 +
remote/remote-main.c | 11 ++
7 files changed, 282 insertions(+)
create mode 100644 hw/proxy/memory-sync.c
create mode 100644 include/hw/proxy/memory-sync.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3da3dcd311..9ebb46722a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2869,6 +2869,8 @@ F: remote/memory.c
F: hw/proxy/Makefile.objs
F: hw/proxy/qemu-proxy.c
F: include/hw/proxy/qemu-proxy.h
+F: include/hw/proxy/memory-sync.h
+F: hw/proxy/memory-sync.c
Build and test automation
-------------------------
diff --git a/Makefile.target b/Makefile.target
index 500fa07fda..c64d860895 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -127,6 +127,9 @@ obj-$(CONFIG_TCG) += fpu/softfloat.o
obj-y += target/$(TARGET_BASE_ARCH)/
obj-y += disas.o
obj-$(call notempty,$(TARGET_XML_FILES)) += gdbstub-xml.o
+ifeq ($(TARGET_NAME)-$(CONFIG_MPQEMU)-$(CONFIG_USER_ONLY), x86_64-y-)
+obj-$(CONFIG_MPQEMU) += hw/proxy/memory-sync.o
+endif
LIBS := $(libs_cpu) $(LIBS)
obj-$(CONFIG_PLUGIN) += plugins/
diff --git a/hw/proxy/memory-sync.c b/hw/proxy/memory-sync.c
new file mode 100644
index 0000000000..b3f57747f3
--- /dev/null
+++ b/hw/proxy/memory-sync.c
@@ -0,0 +1,217 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include <sys/types.h>
+#include <stdio.h>
+#include <string.h>
+
+#include "qemu/osdep.h"
+#include "qemu/compiler.h"
+#include "qemu/int128.h"
+#include "qemu/range.h"
+#include "exec/memory.h"
+#include "exec/cpu-common.h"
+#include "cpu.h"
+#include "exec/ram_addr.h"
+#include "exec/address-spaces.h"
+#include "io/mpqemu-link.h"
+#include "hw/proxy/memory-sync.h"
+
+static const TypeInfo remote_mem_sync_type_info = {
+ .name = TYPE_MEMORY_LISTENER,
+ .parent = TYPE_OBJECT,
+ .instance_size = sizeof(RemoteMemSync),
+};
+
+static void remote_mem_sync_register_types(void)
+{
+ type_register_static(&remote_mem_sync_type_info);
+}
+
+type_init(remote_mem_sync_register_types)
+
+static void proxy_ml_begin(MemoryListener *listener)
+{
+ RemoteMemSync *sync = container_of(listener, RemoteMemSync, listener);
+ int mrs;
+
+ for (mrs = 0; mrs < sync->n_mr_sections; mrs++) {
+ memory_region_unref(sync->mr_sections[mrs].mr);
+ }
+
+ g_free(sync->mr_sections);
+ sync->mr_sections = NULL;
+ sync->n_mr_sections = 0;
+}
+
+static int get_fd_from_hostaddr(uint64_t host, ram_addr_t *offset)
+{
+ MemoryRegion *mr;
+ ram_addr_t off;
+
+ /**
+ * Assumes that the host address is a valid address as it's
+ * coming from the MemoryListener system. In the case host
+ * address is not valid, the following call would return
+ * the default subregion of "system_memory" region, and
+ * not NULL. So it's not possible to check for NULL here.
+ */
+ mr = memory_region_from_host((void *)(uintptr_t)host, &off);
+
+ if (offset) {
+ *offset = off;
+ }
+
+ return memory_region_get_fd(mr);
+}
+
+static bool proxy_mrs_can_merge(uint64_t host, uint64_t prev_host, size_t size)
+{
+ bool merge;
+ int fd1, fd2;
+
+ fd1 = get_fd_from_hostaddr(host, NULL);
+
+ fd2 = get_fd_from_hostaddr(prev_host, NULL);
+
+ merge = (fd1 == fd2);
+
+ merge &= ((prev_host + size) == host);
+
+ return merge;
+}
+
+static void proxy_ml_region_addnop(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+ RemoteMemSync *sync = container_of(listener, RemoteMemSync, listener);
+ bool need_add = true;
+ uint64_t mrs_size, mrs_gpa, mrs_page;
+ uintptr_t mrs_host;
+ RAMBlock *mrs_rb;
+ MemoryRegionSection *prev_sec;
+
+ if (!(memory_region_is_ram(section->mr) &&
+ !memory_region_is_rom(section->mr))) {
+ return;
+ }
+
+ mrs_rb = section->mr->ram_block;
+ mrs_page = (uint64_t)qemu_ram_pagesize(mrs_rb);
+ mrs_size = int128_get64(section->size);
+ mrs_gpa = section->offset_within_address_space;
+ mrs_host = (uintptr_t)memory_region_get_ram_ptr(section->mr) +
+ section->offset_within_region;
+
+ if (get_fd_from_hostaddr(mrs_host, NULL) <= 0) {
+ return;
+ }
+
+ mrs_host = mrs_host & ~(mrs_page - 1);
+ mrs_gpa = mrs_gpa & ~(mrs_page - 1);
+ mrs_size = ROUND_UP(mrs_size, mrs_page);
+
+ if (sync->n_mr_sections) {
+ prev_sec = sync->mr_sections + (sync->n_mr_sections - 1);
+ uint64_t prev_gpa_start = prev_sec->offset_within_address_space;
+ uint64_t prev_size = int128_get64(prev_sec->size);
+ uint64_t prev_gpa_end = range_get_last(prev_gpa_start, prev_size);
+ uint64_t prev_host_start =
+ (uintptr_t)memory_region_get_ram_ptr(prev_sec->mr) +
+ prev_sec->offset_within_region;
+ uint64_t prev_host_end = range_get_last(prev_host_start, prev_size);
+
+ if (mrs_gpa <= (prev_gpa_end + 1)) {
+ g_assert(mrs_gpa > prev_gpa_start);
+
+ if ((section->mr == prev_sec->mr) &&
+ proxy_mrs_can_merge(mrs_host, prev_host_start,
+ (mrs_gpa - prev_gpa_start))) {
+ uint64_t max_end = MAX(prev_host_end, mrs_host + mrs_size);
+ need_add = false;
+ prev_sec->offset_within_address_space =
+ MIN(prev_gpa_start, mrs_gpa);
+ prev_sec->offset_within_region =
+ MIN(prev_host_start, mrs_host) -
+ (uintptr_t)memory_region_get_ram_ptr(prev_sec->mr);
+ prev_sec->size = int128_make64(max_end - MIN(prev_host_start,
+ mrs_host));
+ }
+ }
+ }
+
+ if (need_add) {
+ ++sync->n_mr_sections;
+ sync->mr_sections = g_renew(MemoryRegionSection, sync->mr_sections,
+ sync->n_mr_sections);
+ sync->mr_sections[sync->n_mr_sections - 1] = *section;
+ sync->mr_sections[sync->n_mr_sections - 1].fv = NULL;
+ memory_region_ref(section->mr);
+ }
+}
+
+static void proxy_ml_commit(MemoryListener *listener)
+{
+ RemoteMemSync *sync = container_of(listener, RemoteMemSync, listener);
+ MPQemuMsg msg;
+ MemoryRegionSection section;
+ ram_addr_t offset;
+ uintptr_t host_addr;
+ int region;
+
+ memset(&msg, 0, sizeof(MPQemuMsg));
+
+ msg.cmd = SYNC_SYSMEM;
+ msg.bytestream = 0;
+ msg.num_fds = sync->n_mr_sections;
+ msg.size = sizeof(msg.data1);
+ assert(msg.num_fds <= REMOTE_MAX_FDS);
+
+ for (region = 0; region < sync->n_mr_sections; region++) {
+ section = sync->mr_sections[region];
+ msg.data1.sync_sysmem.gpas[region] =
+ section.offset_within_address_space;
+ msg.data1.sync_sysmem.sizes[region] = int128_get64(section.size);
+ host_addr = (uintptr_t)memory_region_get_ram_ptr(section.mr) +
+ section.offset_within_region;
+ msg.fds[region] = get_fd_from_hostaddr(host_addr, &offset);
+ msg.data1.sync_sysmem.offsets[region] = offset;
+ }
+ mpqemu_msg_send(&msg, sync->mpqemu_link->com);
+}
+
+void deconfigure_memory_sync(RemoteMemSync *sync)
+{
+ memory_listener_unregister(&sync->listener);
+}
+
+/*
+ * TODO: Memory Sync need not be instantianted once per every proxy device.
+ * All remote devices are going to get the exact same updates at the
+ * same time. It therefore makes sense to have a broadcast model.
+ *
+ * Broadcast model would involve running the MemorySync object in a
+ * thread. MemorySync would contain a list of mpqemu-link objects
+ * that need notification. proxy_ml_commit() could send the same
+ * message to all the links at the same time.
+ */
+void configure_memory_sync(RemoteMemSync *sync, MPQemuLinkState *mpqemu_link)
+{
+ sync->n_mr_sections = 0;
+ sync->mr_sections = NULL;
+
+ sync->mpqemu_link = mpqemu_link;
+
+ sync->listener.begin = proxy_ml_begin;
+ sync->listener.commit = proxy_ml_commit;
+ sync->listener.region_add = proxy_ml_region_addnop;
+ sync->listener.region_nop = proxy_ml_region_addnop;
+ sync->listener.priority = 10;
+
+ memory_listener_register(&sync->listener, &address_space_memory);
+}
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index 7fd0a312a5..2ac4c1528a 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -13,6 +13,8 @@
#include "io/mpqemu-link.h"
#include "hw/proxy/qemu-proxy.h"
#include "hw/pci/pci.h"
+#include "hw/proxy/memory-sync.h"
+#include "qom/object.h"
static int config_op_send(PCIProxyDev *dev, uint32_t addr, uint32_t *val, int l,
unsigned int op)
@@ -138,6 +140,10 @@ static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
error_propagate(errp, local_err);
}
}
+
+ dev->sync = REMOTE_MEM_SYNC(object_new(TYPE_MEMORY_LISTENER));
+
+ configure_memory_sync(dev->sync, dev->mpqemu_link);
}
static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
diff --git a/include/hw/proxy/memory-sync.h b/include/hw/proxy/memory-sync.h
new file mode 100644
index 0000000000..d8329c9b52
--- /dev/null
+++ b/include/hw/proxy/memory-sync.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef MEMORY_SYNC_H
+#define MEMORY_SYNC_H
+
+#include <sys/types.h>
+
+#include "qemu/osdep.h"
+#include "qom/object.h"
+#include "exec/memory.h"
+#include "io/mpqemu-link.h"
+
+#define TYPE_MEMORY_LISTENER "memory-listener"
+#define REMOTE_MEM_SYNC(obj) \
+ OBJECT_CHECK(RemoteMemSync, (obj), TYPE_MEMORY_LISTENER)
+
+typedef struct RemoteMemSync {
+ Object obj;
+
+ MemoryListener listener;
+
+ int n_mr_sections;
+ MemoryRegionSection *mr_sections;
+
+ MPQemuLinkState *mpqemu_link;
+} RemoteMemSync;
+
+void configure_memory_sync(RemoteMemSync *sync, MPQemuLinkState *mpqemu_link);
+void deconfigure_memory_sync(RemoteMemSync *sync);
+
+#endif
diff --git a/include/hw/proxy/qemu-proxy.h b/include/hw/proxy/qemu-proxy.h
index 9e4127eccb..6d14876ba9 100644
--- a/include/hw/proxy/qemu-proxy.h
+++ b/include/hw/proxy/qemu-proxy.h
@@ -14,6 +14,7 @@
#include "io/mpqemu-link.h"
#include "hw/pci/pci.h"
+#include "hw/proxy/memory-sync.h"
#define TYPE_PCI_PROXY_DEV "pci-proxy-dev"
@@ -39,8 +40,13 @@ typedef struct ProxyMemoryRegion {
struct PCIProxyDev {
PCIDevice parent_dev;
+ int n_mr_sections;
+ MemoryRegionSection *mr_sections;
+
MPQemuLinkState *mpqemu_link;
+ RemoteMemSync *sync;
+
int socket;
ProxyMemoryRegion region[PCI_NUM_REGIONS];
diff --git a/remote/remote-main.c b/remote/remote-main.c
index 0990509f7a..90f241064f 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -35,6 +35,7 @@
#include "exec/ramlist.h"
#include "remote/remote-common.h"
#include "exec/memattrs.h"
+#include "exec/address-spaces.h"
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan);
@@ -231,6 +232,16 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
goto finalize_loop;
}
break;
+ case SYNC_SYSMEM:
+ /*
+ * TODO: ensure no active DMA is happening when
+ * sysmem is being updated
+ */
+ remote_sysmem_reconfig(msg, &err);
+ if (err) {
+ goto finalize_loop;
+ }
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (21 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 15:57 ` Stefan Hajnoczi
2020-05-12 16:12 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process elena.ufimtseva
` (15 subsequent siblings)
38 siblings, 2 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
IOHUB object is added to manage PCI IRQs. It uses KVM_IRQFD
ioctl to create irqfd to injecting PCI interrupts to the guest.
IOHUB object forwards the irqfd to the remote process. Remote process
uses this fd to directly send interrupts to the guest, bypassing QEMU.
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
MAINTAINERS | 2 +
Makefile.target | 1 +
hw/Makefile.objs | 2 -
hw/proxy/Makefile.objs | 1 -
hw/proxy/qemu-proxy.c | 52 ++++++++++++
include/hw/pci/pci_ids.h | 3 +
include/hw/proxy/qemu-proxy.h | 8 ++
include/io/mpqemu-link.h | 8 ++
include/remote/iohub.h | 50 ++++++++++++
include/remote/machine.h | 2 +
io/mpqemu-link.c | 1 +
remote/Makefile.objs | 1 +
remote/iohub.c | 148 ++++++++++++++++++++++++++++++++++
remote/machine.c | 15 ++++
remote/remote-main.c | 4 +
15 files changed, 295 insertions(+), 3 deletions(-)
delete mode 100644 hw/proxy/Makefile.objs
create mode 100644 include/remote/iohub.h
create mode 100644 remote/iohub.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ebb46722a..198c9f69bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2871,6 +2871,8 @@ F: hw/proxy/qemu-proxy.c
F: include/hw/proxy/qemu-proxy.h
F: include/hw/proxy/memory-sync.h
F: hw/proxy/memory-sync.c
+F: include/remote/iohub.h
+F: remote/iohub.c
Build and test automation
-------------------------
diff --git a/Makefile.target b/Makefile.target
index c64d860895..b956ab24f6 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -129,6 +129,7 @@ obj-y += disas.o
obj-$(call notempty,$(TARGET_XML_FILES)) += gdbstub-xml.o
ifeq ($(TARGET_NAME)-$(CONFIG_MPQEMU)-$(CONFIG_USER_ONLY), x86_64-y-)
obj-$(CONFIG_MPQEMU) += hw/proxy/memory-sync.o
+obj-$(CONFIG_MPQEMU) += hw/proxy/qemu-proxy.o
endif
LIBS := $(libs_cpu) $(LIBS)
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 7b489b12a5..af9235b6f2 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -45,8 +45,6 @@ endif
common-obj-y += $(devices-dirs-y)
obj-y += $(devices-dirs-y)
-common-obj-$(CONFIG_MPQEMU) += proxy/
-
remote-pci-obj-$(CONFIG_MPQEMU) += core/
remote-pci-obj-$(CONFIG_MPQEMU) += block/
remote-pci-obj-$(CONFIG_MPQEMU) += pci/
diff --git a/hw/proxy/Makefile.objs b/hw/proxy/Makefile.objs
deleted file mode 100644
index eb81624cf8..0000000000
--- a/hw/proxy/Makefile.objs
+++ /dev/null
@@ -1 +0,0 @@
-common-obj-$(CONFIG_MPQEMU) += qemu-proxy.o
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index 2ac4c1528a..a78694736b 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -15,6 +15,9 @@
#include "hw/pci/pci.h"
#include "hw/proxy/memory-sync.h"
#include "qom/object.h"
+#include "qemu/event_notifier.h"
+#include "sysemu/kvm.h"
+#include "util/event_notifier-posix.c"
static int config_op_send(PCIProxyDev *dev, uint32_t addr, uint32_t *val, int l,
unsigned int op)
@@ -75,6 +78,53 @@ static void pci_proxy_write_config(PCIDevice *d, uint32_t addr, uint32_t val,
config_op_send(PCI_PROXY_DEV(d), addr, &val, l, PCI_CONFIG_WRITE);
}
+static void proxy_intx_update(PCIDevice *pci_dev)
+{
+ PCIProxyDev *dev = PCI_PROXY_DEV(pci_dev);
+ PCIINTxRoute route;
+ int pin = pci_get_byte(pci_dev->config + PCI_INTERRUPT_PIN) - 1;
+
+ if (dev->irqfd.fd) {
+ dev->irqfd.flags = KVM_IRQFD_FLAG_DEASSIGN;
+ (void) kvm_vm_ioctl(kvm_state, KVM_IRQFD, &dev->irqfd);
+ memset(&dev->irqfd, 0, sizeof(struct kvm_irqfd));
+ }
+
+ route = pci_device_route_intx_to_irq(pci_dev, pin);
+
+ dev->irqfd.fd = event_notifier_get_fd(&dev->intr);
+ dev->irqfd.resamplefd = event_notifier_get_fd(&dev->resample);
+ dev->irqfd.gsi = route.irq;
+ dev->irqfd.flags |= KVM_IRQFD_FLAG_RESAMPLE;
+ (void) kvm_vm_ioctl(kvm_state, KVM_IRQFD, &dev->irqfd);
+}
+
+static void setup_irqfd(PCIProxyDev *dev)
+{
+ PCIDevice *pci_dev = PCI_DEVICE(dev);
+ MPQemuMsg msg;
+
+ event_notifier_init(&dev->intr, 0);
+ event_notifier_init(&dev->resample, 0);
+
+ memset(&msg, 0, sizeof(MPQemuMsg));
+ msg.cmd = SET_IRQFD;
+ msg.num_fds = 2;
+ msg.fds[0] = event_notifier_get_fd(&dev->intr);
+ msg.fds[1] = event_notifier_get_fd(&dev->resample);
+ msg.data1.set_irqfd.intx =
+ pci_get_byte(pci_dev->config + PCI_INTERRUPT_PIN) - 1;
+ msg.size = sizeof(msg.data1);
+
+ mpqemu_msg_send(&msg, dev->mpqemu_link->dev);
+
+ memset(&dev->irqfd, 0, sizeof(struct kvm_irqfd));
+
+ proxy_intx_update(pci_dev);
+
+ pci_device_set_intx_routing_notifier(pci_dev, proxy_intx_update);
+}
+
static void proxy_set_socket(Object *obj, const char *str, Error **errp)
{
PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
@@ -144,6 +194,8 @@ static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
dev->sync = REMOTE_MEM_SYNC(object_new(TYPE_MEMORY_LISTENER));
configure_memory_sync(dev->sync, dev->mpqemu_link);
+
+ setup_irqfd(dev);
}
static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
index 11f8ab7149..bd0c17dc78 100644
--- a/include/hw/pci/pci_ids.h
+++ b/include/hw/pci/pci_ids.h
@@ -192,6 +192,9 @@
#define PCI_DEVICE_ID_SUN_SIMBA 0x5000
#define PCI_DEVICE_ID_SUN_SABRE 0xa000
+#define PCI_VENDOR_ID_ORACLE 0x108e
+#define PCI_DEVICE_ID_REMOTE_IOHUB 0xb000
+
#define PCI_VENDOR_ID_CMD 0x1095
#define PCI_DEVICE_ID_CMD_646 0x0646
diff --git a/include/hw/proxy/qemu-proxy.h b/include/hw/proxy/qemu-proxy.h
index 6d14876ba9..0d8ec6d686 100644
--- a/include/hw/proxy/qemu-proxy.h
+++ b/include/hw/proxy/qemu-proxy.h
@@ -12,9 +12,12 @@
#include "qemu/osdep.h"
#include "qemu-common.h"
+#include <linux/kvm.h>
+
#include "io/mpqemu-link.h"
#include "hw/pci/pci.h"
#include "hw/proxy/memory-sync.h"
+#include "qemu/event_notifier.h"
#define TYPE_PCI_PROXY_DEV "pci-proxy-dev"
@@ -47,6 +50,11 @@ struct PCIProxyDev {
RemoteMemSync *sync;
+ struct kvm_irqfd irqfd;
+
+ EventNotifier intr;
+ EventNotifier resample;
+
int socket;
ProxyMemoryRegion region[PCI_NUM_REGIONS];
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index 41cf092f9e..14e4be2bd0 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -33,6 +33,8 @@
* SYNC_SYSMEM Shares QEMU's RAM with remote device's RAM
* BAR_WRITE Writes to PCI BAR region
* BAR_READ Reads from PCI BAR region
+ * SET_IRQFD Sets the IRQFD to be used to raise interrupts directly
+ * from remote device
*
* proc_cmd_t enum type to specify the command to be executed on the remote
* device.
@@ -45,6 +47,7 @@ typedef enum {
PCI_CONFIG_READ,
BAR_WRITE,
BAR_READ,
+ SET_IRQFD,
MAX,
} mpqemu_cmd_t;
@@ -81,6 +84,10 @@ typedef struct {
*
*/
+typedef struct {
+ int intx;
+} set_irqfd_msg_t;
+
typedef struct {
mpqemu_cmd_t cmd;
int bytestream;
@@ -90,6 +97,7 @@ typedef struct {
uint64_t u64;
sync_sysmem_msg_t sync_sysmem;
bar_access_msg_t bar_access;
+ set_irqfd_msg_t set_irqfd;
} data1;
int fds[REMOTE_MAX_FDS];
diff --git a/include/remote/iohub.h b/include/remote/iohub.h
new file mode 100644
index 0000000000..7a488a8c38
--- /dev/null
+++ b/include/remote/iohub.h
@@ -0,0 +1,50 @@
+/*
+ * IO Hub for remote device
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef REMOTE_IOHUB_H
+#define REMOTE_IOHUB_H
+
+#include <sys/types.h>
+
+#include "qemu/osdep.h"
+#include "hw/pci/pci.h"
+#include "qemu/event_notifier.h"
+#include "qemu/thread-posix.h"
+#include "io/mpqemu-link.h"
+
+#define REMOTE_IOHUB_NB_PIRQS 8
+
+#define REMOTE_IOHUB_DEV 31
+#define REMOTE_IOHUB_FUNC 0
+
+#define TYPE_REMOTE_IOHUB_DEVICE "remote-iohub"
+#define REMOTE_IOHUB_DEVICE(obj) \
+ OBJECT_CHECK(RemoteIOHubState, (obj), TYPE_REMOTE_IOHUB_DEVICE)
+
+typedef struct ResampleToken {
+ void *iohub;
+ int pirq;
+} ResampleToken;
+
+typedef struct RemoteIOHubState {
+ PCIDevice d;
+ uint8_t irq_num[PCI_SLOT_MAX][PCI_NUM_PINS];
+ EventNotifier irqfds[REMOTE_IOHUB_NB_PIRQS];
+ EventNotifier resamplefds[REMOTE_IOHUB_NB_PIRQS];
+ unsigned int irq_level[REMOTE_IOHUB_NB_PIRQS];
+ ResampleToken token[REMOTE_IOHUB_NB_PIRQS];
+ QemuMutex irq_level_lock[REMOTE_IOHUB_NB_PIRQS];
+} RemoteIOHubState;
+
+int remote_iohub_map_irq(PCIDevice *pci_dev, int intx);
+void remote_iohub_set_irq(void *opaque, int pirq, int level);
+void process_set_irqfd_msg(PCIDevice *pci_dev, MPQemuMsg *msg);
+
+#endif
diff --git a/include/remote/machine.h b/include/remote/machine.h
index 7e9bdbe28e..300394a546 100644
--- a/include/remote/machine.h
+++ b/include/remote/machine.h
@@ -16,11 +16,13 @@
#include "hw/boards.h"
#include "remote/pcihost.h"
#include "qemu/notify.h"
+#include "remote/iohub.h"
typedef struct RemMachineState {
MachineState parent_obj;
RemPCIHost *host;
+ RemoteIOHubState *iohub;
} RemMachineState;
#define TYPE_REMOTE_MACHINE "remote-machine"
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
index 5cb93fc47b..ea519a980e 100644
--- a/io/mpqemu-link.c
+++ b/io/mpqemu-link.c
@@ -389,6 +389,7 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
break;
case BAR_WRITE:
case BAR_READ:
+ case SET_IRQFD:
if (msg->size != sizeof(msg->data1)) {
return false;
}
diff --git a/remote/Makefile.objs b/remote/Makefile.objs
index 55f405d048..ed3e5bd8c4 100644
--- a/remote/Makefile.objs
+++ b/remote/Makefile.objs
@@ -2,3 +2,4 @@ remote-pci-obj-$(CONFIG_MPQEMU) += remote-main.o
remote-pci-obj-$(CONFIG_MPQEMU) += pcihost.o
remote-pci-obj-$(CONFIG_MPQEMU) += machine.o
remote-pci-obj-$(CONFIG_MPQEMU) += ../util/machine-notify.o
+remote-pci-obj-$(CONFIG_MPQEMU) += iohub.o
diff --git a/remote/iohub.c b/remote/iohub.c
new file mode 100644
index 0000000000..a991a4e112
--- /dev/null
+++ b/remote/iohub.c
@@ -0,0 +1,148 @@
+/*
+ * Remote IO Hub
+ *
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include <sys/types.h>
+
+#include "qemu/osdep.h"
+#include "hw/pci/pci.h"
+#include "hw/pci/pci_ids.h"
+#include "hw/pci/pci_bus.h"
+#include "remote/iohub.h"
+#include "qemu/thread.h"
+#include "hw/boards.h"
+#include "remote/machine.h"
+#include "qemu/main-loop.h"
+
+static void remote_iohub_initfn(Object *obj)
+{
+ RemoteIOHubState *iohub = REMOTE_IOHUB_DEVICE(obj);
+ int slot, intx, pirq;
+
+ memset(&iohub->irqfds, 0, sizeof(iohub->irqfds));
+ memset(&iohub->resamplefds, 0, sizeof(iohub->resamplefds));
+
+ for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
+ for (intx = 0; intx < PCI_NUM_PINS; intx++) {
+ iohub->irq_num[slot][intx] = (slot + intx) % 4 + 4;
+ }
+ }
+
+ for (pirq = 0; pirq < REMOTE_IOHUB_NB_PIRQS; pirq++) {
+ qemu_mutex_init(&iohub->irq_level_lock[pirq]);
+ iohub->irq_level[pirq] = 0;
+ }
+}
+
+static void remote_iohub_class_init(ObjectClass *klass, void *data)
+{
+ PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+ k->vendor_id = PCI_VENDOR_ID_ORACLE;
+ k->device_id = PCI_DEVICE_ID_REMOTE_IOHUB;
+}
+
+static const TypeInfo remote_iohub_info = {
+ .name = TYPE_REMOTE_IOHUB_DEVICE,
+ .parent = TYPE_PCI_DEVICE,
+ .instance_size = sizeof(RemoteIOHubState),
+ .instance_init = remote_iohub_initfn,
+ .class_init = remote_iohub_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_CONVENTIONAL_PCI_DEVICE },
+ { }
+ }
+};
+
+static void remote_iohub_register(void)
+{
+ type_register_static(&remote_iohub_info);
+}
+
+type_init(remote_iohub_register);
+
+int remote_iohub_map_irq(PCIDevice *pci_dev, int intx)
+{
+ BusState *bus = qdev_get_parent_bus(&pci_dev->qdev);
+ PCIBus *pci_bus = PCI_BUS(bus);
+ PCIDevice *pci_iohub =
+ pci_bus->devices[PCI_DEVFN(REMOTE_IOHUB_DEV, REMOTE_IOHUB_FUNC)];
+ RemoteIOHubState *iohub = REMOTE_IOHUB_DEVICE(pci_iohub);
+
+ return iohub->irq_num[PCI_SLOT(pci_dev->devfn)][intx];
+}
+
+/*
+ * TODO: Using lock to set the interrupt level could become a
+ * performance bottleneck. Check if atomic arithmetic
+ * is possible.
+ */
+void remote_iohub_set_irq(void *opaque, int pirq, int level)
+{
+ RemoteIOHubState *iohub = opaque;
+
+ assert(pirq >= 0);
+ assert(pirq < REMOTE_IOHUB_NB_PIRQS);
+
+ qemu_mutex_lock(&iohub->irq_level_lock[pirq]);
+
+ if (level) {
+ if (++iohub->irq_level[pirq] == 1) {
+ event_notifier_set(&iohub->irqfds[pirq]);
+ }
+ } else if (iohub->irq_level[pirq] > 0) {
+ iohub->irq_level[pirq]--;
+ }
+
+ qemu_mutex_unlock(&iohub->irq_level_lock[pirq]);
+}
+
+static void intr_resample_handler(void *opaque)
+{
+ ResampleToken *token = opaque;
+ RemoteIOHubState *iohub = token->iohub;
+ int pirq, s;
+
+ pirq = token->pirq;
+
+ s = event_notifier_test_and_clear(&iohub->resamplefds[pirq]);
+
+ assert(s >= 0);
+
+ qemu_mutex_lock(&iohub->irq_level_lock[pirq]);
+
+ if (iohub->irq_level[pirq]) {
+ event_notifier_set(&iohub->irqfds[pirq]);
+ }
+
+ qemu_mutex_unlock(&iohub->irq_level_lock[pirq]);
+}
+
+void process_set_irqfd_msg(PCIDevice *pci_dev, MPQemuMsg *msg)
+{
+ RemMachineState *machine = REMOTE_MACHINE(current_machine);
+ RemoteIOHubState *iohub = machine->iohub;
+ int pirq = remote_iohub_map_irq(pci_dev, msg->data1.set_irqfd.intx);
+
+ assert(msg->num_fds == 2);
+
+ if (event_notifier_get_fd(&iohub->irqfds[pirq]) != -1) {
+ event_notifier_cleanup(&iohub->irqfds[pirq]);
+ event_notifier_cleanup(&iohub->resamplefds[pirq]);
+ memset(&iohub->token[pirq], 0, sizeof(ResampleToken));
+ }
+
+ event_notifier_init_fd(&iohub->irqfds[pirq], msg->fds[0]);
+ event_notifier_init_fd(&iohub->resamplefds[pirq], msg->fds[1]);
+
+ iohub->token[pirq].iohub = iohub;
+ iohub->token[pirq].pirq = pirq;
+
+ qemu_set_fd_handler(msg->fds[1], intr_resample_handler, NULL,
+ &iohub->token[pirq]);
+}
diff --git a/remote/machine.c b/remote/machine.c
index 97e4f194ea..d529f68660 100644
--- a/remote/machine.c
+++ b/remote/machine.c
@@ -25,12 +25,16 @@
#include "qemu-common.h"
#include "sysemu/sysemu.h"
#include "qemu/notify.h"
+#include "hw/pci/pci_host.h"
+#include "remote/iohub.h"
static void remote_machine_init(Object *obj)
{
RemMachineState *s = REMOTE_MACHINE(obj);
RemPCIHost *rem_host;
MemoryRegion *system_memory, *system_io, *pci_memory;
+ PCIHostState *pci_host;
+ PCIDevice *pci_dev;
Error *error_abort = NULL;
@@ -67,6 +71,17 @@ static void remote_machine_init(Object *obj)
qemu_mutex_unlock_iothread();
qdev_init_nofail(DEVICE(rem_host));
+
+ pci_host = PCI_HOST_BRIDGE(rem_host);
+ pci_dev = pci_create_simple_multifunction(pci_host->bus,
+ PCI_DEVFN(REMOTE_IOHUB_DEV,
+ REMOTE_IOHUB_FUNC),
+ true, TYPE_REMOTE_IOHUB_DEVICE);
+
+ s->iohub = REMOTE_IOHUB_DEVICE(pci_dev);
+
+ pci_bus_irqs(pci_host->bus, remote_iohub_set_irq, remote_iohub_map_irq,
+ s->iohub, REMOTE_IOHUB_NB_PIRQS);
}
static const TypeInfo remote_machine = {
diff --git a/remote/remote-main.c b/remote/remote-main.c
index 90f241064f..7cc1a60c3d 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -36,6 +36,7 @@
#include "remote/remote-common.h"
#include "exec/memattrs.h"
#include "exec/address-spaces.h"
+#include "remote/iohub.h"
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan);
@@ -242,6 +243,9 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
goto finalize_loop;
}
break;
+ case SET_IRQFD:
+ process_set_irqfd_msg(LINK_TO_DEV(link), msg);
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (22 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq elena.ufimtseva
@ 2020-04-23 4:13 ` elena.ufimtseva
2020-05-12 16:07 ` Stefan Hajnoczi
2020-04-23 4:14 ` [PATCH RESEND v6 25/36] multi-process: Introduce build flags to separate remote process code elena.ufimtseva
` (14 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:13 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Jagannathan Raman <jag.raman@oracle.com>
Retrieve PCI configuration info about the remote device and
configure the Proxy PCI object based on the returned information
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
hw/proxy/qemu-proxy.c | 84 ++++++++++++++++++++++++++++++++++++++++
include/io/mpqemu-link.h | 10 +++++
remote/remote-main.c | 21 ++++++++++
3 files changed, 115 insertions(+)
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index a78694736b..730e28483e 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -19,6 +19,8 @@
#include "sysemu/kvm.h"
#include "util/event_notifier-posix.c"
+static void probe_pci_info(PCIDevice *dev);
+
static int config_op_send(PCIProxyDev *dev, uint32_t addr, uint32_t *val, int l,
unsigned int op)
{
@@ -182,8 +184,12 @@ static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
{
PCIProxyDev *dev = PCI_PROXY_DEV(device);
PCIProxyDevClass *k = PCI_PROXY_DEV_GET_CLASS(dev);
+ uint8_t *pci_conf = device->config;
Error *local_err = NULL;
+ pci_conf[PCI_LATENCY_TIMER] = 0xff;
+ pci_conf[PCI_INTERRUPT_PIN] = 0x01;
+
if (k->realize) {
k->realize(dev, &local_err);
if (local_err) {
@@ -196,6 +202,8 @@ static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
configure_memory_sync(dev->sync, dev->mpqemu_link);
setup_irqfd(dev);
+
+ probe_pci_info(PCI_DEVICE(dev));
}
static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
@@ -291,3 +299,79 @@ const MemoryRegionOps proxy_default_ops = {
.max_access_size = 1,
},
};
+
+static void probe_pci_info(PCIDevice *dev)
+{
+ PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
+ DeviceClass *dc = DEVICE_CLASS(pc);
+ PCIProxyDev *pdev = PCI_PROXY_DEV(dev);
+ MPQemuLinkState *mpqemu_link = pdev->mpqemu_link;
+ MPQemuMsg msg, ret;
+ uint32_t orig_val, new_val, class;
+ uint8_t type;
+ int i, size;
+ char *name;
+
+ memset(&msg, 0, sizeof(MPQemuMsg));
+ msg.bytestream = 0;
+ msg.size = 0;
+ msg.cmd = GET_PCI_INFO;
+ mpqemu_msg_send(&msg, mpqemu_link->dev);
+
+ mpqemu_msg_recv(&ret, mpqemu_link->dev);
+
+ pc->vendor_id = ret.data1.ret_pci_info.vendor_id;
+ pc->device_id = ret.data1.ret_pci_info.device_id;
+ pc->class_id = ret.data1.ret_pci_info.class_id;
+ pc->subsystem_id = ret.data1.ret_pci_info.subsystem_id;
+
+ config_op_send(pdev, 11, &class, 1, PCI_CONFIG_READ);
+ switch (class) {
+ case PCI_BASE_CLASS_BRIDGE:
+ set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+ break;
+ case PCI_BASE_CLASS_STORAGE:
+ set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
+ break;
+ case PCI_BASE_CLASS_NETWORK:
+ set_bit(DEVICE_CATEGORY_NETWORK, dc->categories);
+ break;
+ case PCI_BASE_CLASS_INPUT:
+ set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
+ break;
+ case PCI_BASE_CLASS_DISPLAY:
+ set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
+ break;
+ case PCI_BASE_CLASS_PROCESSOR:
+ set_bit(DEVICE_CATEGORY_CPU, dc->categories);
+ break;
+ default:
+ set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+ break;
+ }
+
+ for (i = 0; i < 6; i++) {
+ config_op_send(pdev, 0x10 + (4 * i), &orig_val, 4, PCI_CONFIG_READ);
+ new_val = 0xffffffff;
+ config_op_send(pdev, 0x10 + (4 * i), &new_val, 4, PCI_CONFIG_WRITE);
+ config_op_send(pdev, 0x10 + (4 * i), &new_val, 4, PCI_CONFIG_READ);
+ size = (~(new_val & 0xFFFFFFF0)) + 1;
+ config_op_send(pdev, 0x10 + (4 * i), &orig_val, 4, PCI_CONFIG_WRITE);
+ type = (new_val & 0x1) ?
+ PCI_BASE_ADDRESS_SPACE_IO : PCI_BASE_ADDRESS_SPACE_MEMORY;
+
+ if (size) {
+ pdev->region[i].dev = pdev;
+ pdev->region[i].present = true;
+ if (type == PCI_BASE_ADDRESS_SPACE_MEMORY) {
+ pdev->region[i].memory = true;
+ }
+ name = g_strdup_printf("bar-region-%d", i);
+ memory_region_init_io(&pdev->region[i].mr, OBJECT(pdev),
+ &proxy_default_ops, &pdev->region[i],
+ name, size);
+ pci_register_bar(dev, i, type, &pdev->region[i].mr);
+ g_free(name);
+ }
+ }
+}
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index 14e4be2bd0..102c736705 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -48,6 +48,8 @@ typedef enum {
BAR_WRITE,
BAR_READ,
SET_IRQFD,
+ GET_PCI_INFO,
+ RET_PCI_INFO,
MAX,
} mpqemu_cmd_t;
@@ -70,6 +72,13 @@ typedef struct {
bool memory;
} bar_access_msg_t;
+typedef struct {
+ uint16_t vendor_id;
+ uint16_t device_id;
+ uint16_t class_id;
+ uint16_t subsystem_id;
+} ret_pci_info_msg_t;
+
/**
* MPQemuMsg:
* @cmd: The remote command
@@ -98,6 +107,7 @@ typedef struct {
sync_sysmem_msg_t sync_sysmem;
bar_access_msg_t bar_access;
set_irqfd_msg_t set_irqfd;
+ ret_pci_info_msg_t ret_pci_info;
} data1;
int fds[REMOTE_MAX_FDS];
diff --git a/remote/remote-main.c b/remote/remote-main.c
index 7cc1a60c3d..f5a479e9b2 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -188,6 +188,24 @@ fail:
PUT_REMOTE_WAIT(wait);
}
+static void process_get_pci_info_msg(MPQemuLinkState *link, MPQemuMsg *msg)
+{
+ PCIDevice *pci_dev = LINK_TO_DEV(link);
+ PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
+ MPQemuMsg ret = { 0 };
+
+ ret.cmd = RET_PCI_INFO;
+
+ ret.data1.ret_pci_info.vendor_id = pc->vendor_id;
+ ret.data1.ret_pci_info.device_id = pc->device_id;
+ ret.data1.ret_pci_info.class_id = pc->class_id;
+ ret.data1.ret_pci_info.subsystem_id = pc->subsystem_id;
+
+ ret.size = sizeof(ret.data1);
+
+ mpqemu_msg_send(&ret, link->dev);
+}
+
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan)
{
@@ -246,6 +264,9 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
case SET_IRQFD:
process_set_irqfd_msg(LINK_TO_DEV(link), msg);
break;
+ case GET_PCI_INFO:
+ process_get_pci_info_msg(link, msg);
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 25/36] multi-process: Introduce build flags to separate remote process code
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (23 preceding siblings ...)
2020-04-23 4:13 ` [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 26/36] multi-process: add parse_cmdline in remote process elena.ufimtseva
` (13 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Introduce SCSI_PROCESS & REMOTE_PROCESS build flags to separate
code that applies only to remote processes.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
Makefile.target | 4 ++++
rules.mak | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Makefile.target b/Makefile.target
index b956ab24f6..adc76886f8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -269,6 +269,10 @@ ifdef CONFIG_DARWIN
$(call quiet-command,SetFile -a C $@,"SETFILE","$(TARGET_DIR)$@")
endif
+ifdef CONFIG_MPQEMU
+$(SCSI_DEV_BUILD): REMOTE_FLAGS = -DREMOTE_PROCESS -DSCSI_PROCESS
+endif
+
$(SCSI_DEV_BUILD): $(all-remote-lsi-obj-y) $(COMMON_LDADDS)
$(call LINK, $(filter-out %.mak, $^))
ifdef CONFIG_DARWIN
diff --git a/rules.mak b/rules.mak
index 694865b63e..257f07e322 100644
--- a/rules.mak
+++ b/rules.mak
@@ -67,7 +67,7 @@ expand-objs = $(strip $(sort $(filter %.o,$1)) \
%.o: %.c
$(call quiet-command,$(CC) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
- $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) \
+ $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) $(REMOTE_FLAGS) \
-c -o $@ $<,"CC","$(TARGET_DIR)$@")
%.o: %.rc
$(call quiet-command,$(WINDRES) -I. -o $@ $<,"RC","$(TARGET_DIR)$@")
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 26/36] multi-process: add parse_cmdline in remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (24 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 25/36] multi-process: Introduce build flags to separate remote process code elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 27/36] multi-process: add support to parse device option elena.ufimtseva
` (12 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
MAINTAINERS | 2 ++
remote/Makefile.objs | 1 +
remote/remote-main.c | 21 ++++++++++++-
remote/remote-opts.c | 75 ++++++++++++++++++++++++++++++++++++++++++++
remote/remote-opts.h | 15 +++++++++
5 files changed, 113 insertions(+), 1 deletion(-)
create mode 100644 remote/remote-opts.c
create mode 100644 remote/remote-opts.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 198c9f69bc..6a4b5e16be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2873,6 +2873,8 @@ F: include/hw/proxy/memory-sync.h
F: hw/proxy/memory-sync.c
F: include/remote/iohub.h
F: remote/iohub.c
+F: remote/remote-opts.h
+F: remote/remote-opts.c
Build and test automation
-------------------------
diff --git a/remote/Makefile.objs b/remote/Makefile.objs
index ed3e5bd8c4..74c3396786 100644
--- a/remote/Makefile.objs
+++ b/remote/Makefile.objs
@@ -1,4 +1,5 @@
remote-pci-obj-$(CONFIG_MPQEMU) += remote-main.o
+remote-pci-obj-$(CONFIG_MPQEMU) += remote-opts.o
remote-pci-obj-$(CONFIG_MPQEMU) += pcihost.o
remote-pci-obj-$(CONFIG_MPQEMU) += machine.o
remote-pci-obj-$(CONFIG_MPQEMU) += ../util/machine-notify.o
diff --git a/remote/remote-main.c b/remote/remote-main.c
index f5a479e9b2..b37802151a 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -24,6 +24,7 @@
#include "io/mpqemu-link.h"
#include "qapi/error.h"
#include "qemu/main-loop.h"
+#include "qemu/cutils.h"
#include "sysemu/cpus.h"
#include "qemu-common.h"
#include "hw/pci/pci.h"
@@ -37,6 +38,7 @@
#include "exec/memattrs.h"
#include "exec/address-spaces.h"
#include "remote/iohub.h"
+#include "remote-opts.h"
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan);
@@ -289,6 +291,7 @@ finalize_loop:
int main(int argc, char *argv[])
{
Error *err = NULL;
+ int fd = -1;
module_call_init(MODULE_INIT_QOM);
@@ -307,6 +310,13 @@ int main(int argc, char *argv[])
current_machine = MACHINE(REMOTE_MACHINE(object_new(TYPE_REMOTE_MACHINE)));
+ qemu_add_opts(&qemu_device_opts);
+ qemu_add_opts(&qemu_drive_opts);
+ qemu_add_drive_opts(&qemu_legacy_drive_opts);
+ qemu_add_drive_opts(&qemu_common_drive_opts);
+ qemu_add_drive_opts(&qemu_drive_opts);
+ qemu_add_drive_opts(&bdrv_runtime_opts);
+
mpqemu_link = mpqemu_link_create();
if (!mpqemu_link) {
printf("Could not create MPQemu link pid %d, exec_name %s",
@@ -314,7 +324,16 @@ int main(int argc, char *argv[])
return -1;
}
- mpqemu_init_channel(mpqemu_link, &mpqemu_link->com, STDIN_FILENO);
+ fd = qemu_parse_fd(argv[1]);
+ if (fd == -1) {
+ printf("Failed to parse fd for remote process pid %d, exec_name %s\n",
+ getpid(), __progname);
+ return -EINVAL;
+ }
+
+ parse_cmdline(argc - 2, argv + 2, NULL);
+
+ mpqemu_init_channel(mpqemu_link, &mpqemu_link->com, fd);
mpqemu_link_set_callback(mpqemu_link, process_msg);
diff --git a/remote/remote-opts.c b/remote/remote-opts.c
new file mode 100644
index 0000000000..cb7837bf13
--- /dev/null
+++ b/remote/remote-opts.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "hw/boards.h"
+#include "sysemu/blockdev.h"
+#include "qapi/error.h"
+#include "qemu-options.h"
+#include "qemu-parse.h"
+#include "remote-opts.h"
+
+/*
+ * In remote process, we parse only subset of options. The code
+ * taken from vl.c to re-use in remote command line parser.
+ */
+void parse_cmdline(int argc, char **argv, char **envp)
+{
+ int optind;
+ const char *optarg;
+ MachineClass *mc;
+
+ /* from vl.c */
+ optind = 0;
+
+ /* second pass of option parsing */
+
+ for (;;) {
+ if (optind >= argc) {
+ break;
+ }
+ if (argv[optind][0] != '-') {
+ loc_set_cmdline(argv, optind, 1);
+ drive_add(IF_DEFAULT, 0, argv[optind++], HD_OPTS);
+ } else {
+ const QEMUOption *popt;
+
+ popt = lookup_opt(argc, argv, &optarg, &optind);
+ #ifndef REMOTE_PROCESS
+ if (!(popt->arch_mask & arch_type)) {
+ error_report("Option not supported for this target,"
+ " %x arch_mask, %x arch_type",
+ popt->arch_mask, arch_type);
+ exit(1);
+ }
+ #endif
+ switch (popt->index) {
+ case QEMU_OPTION_drive:
+ if (drive_def(optarg) == NULL) {
+ fprintf(stderr, "Could not init drive\n");
+ exit(1);
+ }
+ break;
+ default:
+ break;
+ }
+ }
+ }
+ mc = MACHINE_GET_CLASS(current_machine);
+
+ mc->block_default_type = IF_IDE;
+ if (qemu_opts_foreach(qemu_find_opts("drive"), drive_init_func,
+ &mc->block_default_type, &error_fatal)) {
+ /* We printed help */
+ exit(0);
+ }
+
+ return;
+}
diff --git a/remote/remote-opts.h b/remote/remote-opts.h
new file mode 100644
index 0000000000..263d428060
--- /dev/null
+++ b/remote/remote-opts.h
@@ -0,0 +1,15 @@
+/*
+ * Copyright © 2018, 2020 Oracle and/or its affiliates.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef REMOTE_OPTS_H
+#define REMOTE_OPTS_H
+
+void parse_cmdline(int argc, char **argv, char **envp);
+
+#endif
+
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 27/36] multi-process: add support to parse device option
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (25 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 26/36] multi-process: add parse_cmdline in remote process elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 28/36] multi-process: send heartbeat messages to remote elena.ufimtseva
` (11 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Enable remote process to parse device command line option
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
remote/remote-opts.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/remote/remote-opts.c b/remote/remote-opts.c
index cb7837bf13..f077221c71 100644
--- a/remote/remote-opts.c
+++ b/remote/remote-opts.c
@@ -57,6 +57,13 @@ void parse_cmdline(int argc, char **argv, char **envp)
exit(1);
}
break;
+ case QEMU_OPTION_device:
+ if (!qemu_opts_parse_noisily(qemu_find_opts("device"),
+ optarg, true)) {
+ error_report("Unable to process device command");
+ exit(1);
+ }
+ break;
default:
break;
}
@@ -71,5 +78,8 @@ void parse_cmdline(int argc, char **argv, char **envp)
exit(0);
}
+ qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL,
+ &error_fatal);
+
return;
}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 28/36] multi-process: send heartbeat messages to remote
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (26 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 27/36] multi-process: add support to parse device option elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 29/36] multi-process: handle heartbeat messages in remote process elena.ufimtseva
` (10 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
In order to detect remote processes which are hung, the
proxy periodically sends heartbeat messages to confirm if
the remote process is alive
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
hw/proxy/qemu-proxy.c | 86 +++++++++++++++++++++++++++++++++++
include/hw/proxy/qemu-proxy.h | 3 ++
include/io/mpqemu-link.h | 1 +
io/mpqemu-link.c | 5 ++
4 files changed, 95 insertions(+)
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index 730e28483e..162014353f 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -21,6 +21,78 @@
static void probe_pci_info(PCIDevice *dev);
+static void childsig_handler(int sig, siginfo_t *siginfo, void *ctx)
+{
+ /* TODO: Add proper handler. */
+ printf("Child (pid %d) is dead? Signal is %d, Exit code is %d.\n",
+ siginfo->si_pid, siginfo->si_signo, siginfo->si_code);
+}
+
+static void hb_msg(PCIProxyDev *dev)
+{
+ DeviceState *ds = DEVICE(dev);
+ MPQemuMsg msg = { 0 };
+ uint64_t ret;
+
+ if (event_notifier_get_fd(&dev->en_ping) == -1) {
+ return;
+ }
+
+ memset(&msg, 0, sizeof(MPQemuMsg));
+
+ msg.num_fds = 1;
+ msg.cmd = PROXY_PING;
+ msg.bytestream = 0;
+ msg.size = 0;
+ msg.fds[0] = event_notifier_get_fd(&dev->en_ping);
+
+ mpqemu_msg_send(&msg, dev->mpqemu_link->com);
+
+ ret = wait_for_remote(msg.fds[0]);
+
+ if (ret) {
+ printf("Lost contact with remote device %s\n", ds->id);
+ /* TODO: Initiate error recovery */
+ }
+}
+
+#define NOP_INTERVAL 1000
+
+static void remote_ping(void *opaque)
+{
+ PCIProxyDev *dev = opaque;
+
+ hb_msg(dev);
+
+ timer_mod(dev->hb_timer,
+ qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + NOP_INTERVAL);
+}
+
+static void start_hb_timer(PCIProxyDev *dev)
+{
+ dev->hb_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL,
+ remote_ping,
+ dev);
+
+ timer_mod(dev->hb_timer,
+ qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + NOP_INTERVAL);
+}
+
+static void stop_hb_timer(PCIProxyDev *dev)
+{
+ timer_del(dev->hb_timer);
+ timer_free(dev->hb_timer);
+}
+
+static void set_sigchld_handler(void)
+{
+ struct sigaction sa_sigterm;
+ memset(&sa_sigterm, 0, sizeof(sa_sigterm));
+ sa_sigterm.sa_sigaction = childsig_handler;
+ sa_sigterm.sa_flags = SA_SIGINFO | SA_NOCLDWAIT | SA_NOCLDSTOP;
+ sigaction(SIGCHLD, &sa_sigterm, NULL);
+}
+
static int config_op_send(PCIProxyDev *dev, uint32_t addr, uint32_t *val, int l,
unsigned int op)
{
@@ -204,6 +276,19 @@ static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
setup_irqfd(dev);
probe_pci_info(PCI_DEVICE(dev));
+
+ set_sigchld_handler();
+
+ event_notifier_init(&dev->en_ping, 0);
+
+ start_hb_timer(dev);
+}
+
+static void pci_proxy_dev_exit(PCIDevice *pdev)
+{
+ PCIProxyDev *dev = PCI_PROXY_DEV(pdev);
+
+ stop_hb_timer(dev);
}
static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
@@ -211,6 +296,7 @@ static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
k->realize = pci_proxy_dev_realize;
+ k->exit = pci_proxy_dev_exit;
k->config_read = pci_proxy_read_config;
k->config_write = pci_proxy_write_config;
}
diff --git a/include/hw/proxy/qemu-proxy.h b/include/hw/proxy/qemu-proxy.h
index 0d8ec6d686..26f0a41110 100644
--- a/include/hw/proxy/qemu-proxy.h
+++ b/include/hw/proxy/qemu-proxy.h
@@ -55,6 +55,9 @@ struct PCIProxyDev {
EventNotifier intr;
EventNotifier resample;
+ EventNotifier en_ping;
+ QEMUTimer *hb_timer;
+
int socket;
ProxyMemoryRegion region[PCI_NUM_REGIONS];
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index 102c736705..45ea1fcafa 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -50,6 +50,7 @@ typedef enum {
SET_IRQFD,
GET_PCI_INFO,
RET_PCI_INFO,
+ PROXY_PING,
MAX,
} mpqemu_cmd_t;
diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
index ea519a980e..91a3395566 100644
--- a/io/mpqemu-link.c
+++ b/io/mpqemu-link.c
@@ -394,6 +394,11 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
return false;
}
break;
+ case PROXY_PING:
+ if (msg->size != 0) {
+ return false;
+ }
+ break;
default:
break;
}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 29/36] multi-process: handle heartbeat messages in remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (27 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 28/36] multi-process: send heartbeat messages to remote elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 30/36] multi-process: perform device reset in the " elena.ufimtseva
` (9 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
If the remote process is alive, it responds to proxy's heartbeat
messages
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
remote/remote-main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/remote/remote-main.c b/remote/remote-main.c
index b37802151a..beac591fac 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -216,6 +216,7 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
g_autofree gchar *pid_exec = NULL;
pid_exec = g_malloc(PROC_INFO_LENGTH);
+ int wait;
if ((cond & G_IO_HUP) || (cond & G_IO_ERR)) {
goto finalize_loop;
@@ -269,6 +270,10 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
case GET_PCI_INFO:
process_get_pci_info_msg(link, msg);
break;
+ case PROXY_PING:
+ wait = msg->fds[0];
+ notify_proxy(wait, 0);
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 30/36] multi-process: perform device reset in the remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (28 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 29/36] multi-process: handle heartbeat messages in remote process elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 31/36] multi-process/mon: choose HMP commands based on target elena.ufimtseva
` (8 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Perform device reset in the remote process when QEMU performs
device reset. This is required to reset the internal state
(like registers, etc...) of emulated devices
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
hw/proxy/qemu-proxy.c | 25 +++++++++++++++++++++++++
include/io/mpqemu-link.h | 1 +
remote/remote-main.c | 13 +++++++++++++
3 files changed, 39 insertions(+)
diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
index 162014353f..cffc227acd 100644
--- a/hw/proxy/qemu-proxy.c
+++ b/hw/proxy/qemu-proxy.c
@@ -291,14 +291,39 @@ static void pci_proxy_dev_exit(PCIDevice *pdev)
stop_hb_timer(dev);
}
+static void proxy_device_reset(DeviceState *dev)
+{
+ PCIProxyDev *pdev = PCI_PROXY_DEV(dev);
+ MPQemuMsg msg;
+ int wait = -1;
+
+ memset(&msg, 0, sizeof(MPQemuMsg));
+
+ msg.bytestream = 0;
+ msg.size = sizeof(msg.data1);
+ msg.cmd = DEVICE_RESET;
+
+ wait = GET_REMOTE_WAIT;
+ msg.num_fds = 1;
+ msg.fds[0] = wait;
+
+ mpqemu_msg_send(&msg, pdev->mpqemu_link->com);
+
+ (void)wait_for_remote(wait);
+
+ PUT_REMOTE_WAIT(wait);
+}
+
static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
{
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+ DeviceClass *dc = DEVICE_CLASS(klass);
k->realize = pci_proxy_dev_realize;
k->exit = pci_proxy_dev_exit;
k->config_read = pci_proxy_read_config;
k->config_write = pci_proxy_write_config;
+ dc->reset = proxy_device_reset;
}
static const TypeInfo pci_proxy_dev_type_info = {
diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
index 45ea1fcafa..22fb234744 100644
--- a/include/io/mpqemu-link.h
+++ b/include/io/mpqemu-link.h
@@ -51,6 +51,7 @@ typedef enum {
GET_PCI_INFO,
RET_PCI_INFO,
PROXY_PING,
+ DEVICE_RESET,
MAX,
} mpqemu_cmd_t;
diff --git a/remote/remote-main.c b/remote/remote-main.c
index beac591fac..562db4ccc3 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -39,6 +39,7 @@
#include "exec/address-spaces.h"
#include "remote/iohub.h"
#include "remote-opts.h"
+#include "sysemu/reset.h"
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan);
@@ -208,6 +209,15 @@ static void process_get_pci_info_msg(MPQemuLinkState *link, MPQemuMsg *msg)
mpqemu_msg_send(&ret, link->dev);
}
+static void process_device_reset_msg(MPQemuMsg *msg)
+{
+ qemu_devices_reset();
+
+ if (msg->num_fds == 1) {
+ notify_proxy(msg->fds[0], 0);
+ }
+}
+
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan)
{
@@ -274,6 +284,9 @@ static void process_msg(GIOCondition cond, MPQemuLinkState *link,
wait = msg->fds[0];
notify_proxy(wait, 0);
break;
+ case DEVICE_RESET:
+ process_device_reset_msg(msg);
+ break;
default:
error_setg(&err, "Unknown command in %s", print_pid_exec(pid_exec));
goto finalize_loop;
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 31/36] multi-process/mon: choose HMP commands based on target
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (29 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 30/36] multi-process: perform device reset in the " elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 32/36] multi-process/mon: stub functions to enable QMP module for remote process elena.ufimtseva
` (7 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Add "targets" field to HMP command definition to select the targets
which would be supported by each command
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
hmp-commands-info.hx | 10 ++++++++++
hmp-commands.hx | 20 ++++++++++++++++++++
scripts/hxtool | 35 ++++++++++++++++++++++++++++++++++-
3 files changed, 64 insertions(+), 1 deletion(-)
mode change 100644 => 100755 scripts/hxtool
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index ca5198438d..1fbca7a18d 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -23,6 +23,7 @@ ERST
.params = "",
.help = "show the version of QEMU",
.cmd = hmp_info_version,
+ .targets = "scsi",
.flags = "p",
},
@@ -50,6 +51,7 @@ ERST
.params = "",
.help = "show the character devices",
.cmd = hmp_info_chardev,
+ .targets = "scsi",
.flags = "p",
},
@@ -65,6 +67,7 @@ ERST
.help = "show info of one block device or all block devices "
"(-n: show named nodes; -v: show details)",
.cmd = hmp_info_block,
+ .targets = "scsi",
},
SRST
@@ -78,6 +81,7 @@ ERST
.params = "",
.help = "show block device statistics",
.cmd = hmp_info_blockstats,
+ .targets = "scsi",
},
SRST
@@ -91,6 +95,7 @@ ERST
.params = "",
.help = "show progress of ongoing block device operations",
.cmd = hmp_info_block_jobs,
+ .targets = "scsi",
},
SRST
@@ -161,6 +166,7 @@ ERST
.params = "",
.help = "show the command line history",
.cmd = hmp_info_history,
+ .targets = "scsi",
.flags = "p",
},
@@ -214,6 +220,7 @@ ERST
.params = "",
.help = "show PCI info",
.cmd = hmp_info_pci,
+ .targets = "scsi",
},
SRST
@@ -598,6 +605,7 @@ ERST
.params = "",
.help = "show device tree",
.cmd = hmp_info_qtree,
+ .targets = "scsi",
},
SRST
@@ -611,6 +619,7 @@ ERST
.params = "",
.help = "show qdev device model list",
.cmd = hmp_info_qdm,
+ .targets = "scsi",
},
SRST
@@ -624,6 +633,7 @@ ERST
.params = "[path]",
.help = "show QOM composition tree",
.cmd = hmp_info_qom_tree,
+ .targets = "scsi",
.flags = "p",
},
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 02cae25c24..1b60676d7c 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -45,6 +45,7 @@ ERST
.params = "",
.help = "quit the emulator",
.cmd = hmp_quit,
+ .targets = "scsi",
},
SRST
@@ -76,6 +77,7 @@ ERST
.params = "device size",
.help = "resize a block image",
.cmd = hmp_block_resize,
+ .targets = "scsi",
},
SRST
@@ -92,6 +94,7 @@ ERST
.params = "device [speed [base]]",
.help = "copy data from a backing file into a block device",
.cmd = hmp_block_stream,
+ .targets = "scsi",
},
SRST
@@ -105,6 +108,7 @@ ERST
.params = "device speed",
.help = "set maximum speed for a background block operation",
.cmd = hmp_block_job_set_speed,
+ .targets = "scsi",
},
SRST
@@ -120,6 +124,7 @@ ERST
"\n\t\t\t if you want to abort the operation immediately"
"\n\t\t\t instead of keep running until data is in sync)",
.cmd = hmp_block_job_cancel,
+ .targets = "scsi",
},
SRST
@@ -133,6 +138,7 @@ ERST
.params = "device",
.help = "stop an active background block operation",
.cmd = hmp_block_job_complete,
+ .targets = "scsi",
},
SRST
@@ -147,6 +153,7 @@ ERST
.params = "device",
.help = "pause an active background block operation",
.cmd = hmp_block_job_pause,
+ .targets = "scsi",
},
SRST
@@ -160,6 +167,7 @@ ERST
.params = "device",
.help = "resume a paused background block operation",
.cmd = hmp_block_job_resume,
+ .targets = "scsi",
},
SRST
@@ -173,6 +181,7 @@ ERST
.params = "[-f] device",
.help = "eject a removable medium (use -f to force it)",
.cmd = hmp_eject,
+ .targets = "scsi",
},
SRST
@@ -186,6 +195,7 @@ ERST
.params = "device",
.help = "remove host block device",
.cmd = hmp_drive_del,
+ .targets = "scsi",
},
SRST
@@ -204,6 +214,7 @@ ERST
.params = "device filename [format [read-only-mode]]",
.help = "change a removable medium, optional format",
.cmd = hmp_change,
+ .targets = "scsi",
},
SRST
@@ -671,6 +682,7 @@ ERST
.help = "add device, like -device on the command line",
.cmd = hmp_device_add,
.command_completion = device_add_completion,
+ .targets = "scsi",
},
SRST
@@ -685,6 +697,7 @@ ERST
.help = "remove device",
.cmd = hmp_device_del,
.command_completion = device_del_completion,
+ .targets = "scsi",
},
SRST
@@ -1264,6 +1277,7 @@ ERST
"The -c flag requests QEMU to compress backup data\n\t\t\t"
"(if the target format supports it).\n\t\t\t",
.cmd = hmp_drive_backup,
+ .targets = "scsi",
},
SRST
``drive_backup``
@@ -1280,6 +1294,7 @@ ERST
"[,readonly=on|off][,copy-on-read=on|off]",
.help = "add drive to PCI storage controller",
.cmd = hmp_drive_add,
+ .targets = "scsi",
},
SRST
@@ -1697,6 +1712,7 @@ ERST
.help = "add chardev",
.cmd = hmp_chardev_add,
.command_completion = chardev_add_completion,
+ .targets = "scsi",
},
SRST
@@ -1710,6 +1726,7 @@ ERST
.params = "id args",
.help = "change chardev",
.cmd = hmp_chardev_change,
+ .targets = "scsi",
},
SRST
@@ -1725,6 +1742,7 @@ ERST
.help = "remove chardev",
.cmd = hmp_chardev_remove,
.command_completion = chardev_remove_completion,
+ .targets = "scsi",
},
SRST
@@ -1739,6 +1757,7 @@ ERST
.help = "send a break on chardev",
.cmd = hmp_chardev_send_break,
.command_completion = chardev_remove_completion,
+ .targets = "scsi",
},
SRST
@@ -1810,6 +1829,7 @@ ERST
.params = "[subcommand]",
.help = "show various information about the system state",
.cmd = hmp_info_help,
+ .targets = "scsi",
.sub_table = hmp_info_cmds,
.flags = "p",
},
diff --git a/scripts/hxtool b/scripts/hxtool
old mode 100644
new mode 100755
index 7b1452f3cf..80c6845db1
--- a/scripts/hxtool
+++ b/scripts/hxtool
@@ -10,7 +10,39 @@ hxtoh()
SRST*|ERST*) flag=$(($flag^1))
;;
*)
- test $flag -eq 1 && printf "%s\n" "$str"
+ # Skip line that has ".targets" as it is for multi-process targets based hmp
+ # commands generation.
+ echo $str | grep -q '.targets'
+ if [ $? -eq 0 ]; then
+ continue
+ else
+ test $flag -eq 1 && printf "%s\n" "$str"
+ fi
+ ;;
+ esac
+ done
+}
+
+hxtoh_tgt()
+{
+ section=""
+ flag=1
+ use_section=0
+ while read -r str; do
+ # Print section if it has ".targets" and the second argument passed to the
+ # script, such as "scsi".
+ echo "$str" | grep -q -E ".targets.*$1"
+ if [ $? -eq 0 ]; then
+ use_section=1
+ continue
+ fi
+ case $str in
+ HXCOMM*)
+ ;;
+ SRST*|ERST*) flag=$(($flag^1)); test $use_section -eq 1 && printf '%s' "$section"; section=""; use_section=0
+ ;;
+ *)
+ test $flag -eq 1 && section="${section} ${str} ${IFS}"
;;
esac
done
@@ -18,6 +50,7 @@ hxtoh()
case "$1" in
"-h") hxtoh ;;
+"-tgt") hxtoh_tgt $2 ;;
*) exit 1 ;;
esac
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 32/36] multi-process/mon: stub functions to enable QMP module for remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (30 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 31/36] multi-process/mon: choose HMP commands based on target elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 33/36] multi-process/mon: enable QMP module support in the " elena.ufimtseva
` (6 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
QMP module doesn't need some functions to run independently on the
remote processes. However, these functions are necessary for
compilation. Therefore, these functions are stub'ed out. The
stub functions raise an assert if QEMU is built in debug mode
(--enable-debug).
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
MAINTAINERS | 4 +
accel/stubs/tcg-stub.c | 10 +++
configure | 4 +
include/qemu-common.h | 8 ++
stubs/gdbstub.c | 23 ++++++
stubs/migration.c | 162 +++++++++++++++++++++++++++++++++++++++++
stubs/monitor.c | 31 ++++++++
stubs/net-stub.c | 69 ++++++++++++++++++
stubs/qapi-misc.c | 41 +++++++++++
stubs/qapi-target.c | 56 ++++++++++++++
stubs/ui-stub.c | 130 +++++++++++++++++++++++++++++++++
stubs/vl-stub.c | 92 +++++++++++++++++++++++
12 files changed, 630 insertions(+)
create mode 100644 stubs/migration.c
create mode 100644 stubs/qapi-misc.c
create mode 100644 stubs/qapi-target.c
create mode 100644 stubs/ui-stub.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 6a4b5e16be..216291f545 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1996,6 +1996,8 @@ F: blockdev-hmp-cmds.c
F: block/qapi.c
F: qapi/block*.json
F: qapi/transaction.json
+F: stubs/qapi-misc.c
+F: stubs/qapi-target.c
T: git https://repo.or.cz/qemu/armbru.git block-next
Dirty Bitmaps
@@ -2120,6 +2122,7 @@ F: ui/
F: include/ui/
F: qapi/ui.json
F: util/drm.c
+F: stubs/ui-stub.c
Cocoa graphics
M: Peter Maydell <peter.maydell@linaro.org>
@@ -2152,6 +2155,7 @@ F: include/monitor/hmp-target.h
F: tests/qtest/test-hmp.c
F: include/qemu/qemu-print.h
F: util/qemu-print.c
+F: stubs/migration.c
Network device backends
M: Jason Wang <jasowang@redhat.com>
diff --git a/accel/stubs/tcg-stub.c b/accel/stubs/tcg-stub.c
index 2e4e8741fb..cdbceb5fff 100644
--- a/accel/stubs/tcg-stub.c
+++ b/accel/stubs/tcg-stub.c
@@ -119,4 +119,14 @@ page_collection_lock(tb_page_addr_t start, tb_page_addr_t end)
void page_collection_unlock(struct page_collection *set)
{
}
+
+void dump_exec_info(void)
+{
+ qemu_debug_assert(0);
+}
+
+void dump_opcount_info(void)
+{
+ qemu_debug_assert(0);
+}
#endif
diff --git a/configure b/configure
index 913c78d4ef..cd90cc5d02 100755
--- a/configure
+++ b/configure
@@ -7562,6 +7562,10 @@ if test "$mpqemu" = "yes" ; then
echo "CONFIG_MPQEMU=y" >> $config_host_mak
fi
+if test "$debug" = "yes" ; then
+ echo "CONFIG_DEBUG=y" >> $config_host_mak
+fi
+
if test "$bochs" = "yes" ; then
echo "CONFIG_BOCHS=y" >> $config_host_mak
fi
diff --git a/include/qemu-common.h b/include/qemu-common.h
index d0142f29ac..b76e309d98 100644
--- a/include/qemu-common.h
+++ b/include/qemu-common.h
@@ -10,6 +10,8 @@
#ifndef QEMU_COMMON_H
#define QEMU_COMMON_H
+#include <assert.h>
+
#define TFR(expr) do { if ((expr) != -1) break; } while (errno == EINTR)
/* Copyright string for -version arguments, About dialogs, etc */
@@ -135,4 +137,10 @@ void page_size_init(void);
* returned. */
bool dump_in_progress(void);
+#ifdef CONFIG_DEBUG
+#define qemu_debug_assert(x) assert(x)
+#else
+#define qemu_debug_assert(x)
+#endif
+
#endif
diff --git a/stubs/gdbstub.c b/stubs/gdbstub.c
index 2b7aee50d3..1e65b54755 100644
--- a/stubs/gdbstub.c
+++ b/stubs/gdbstub.c
@@ -1,6 +1,29 @@
#include "qemu/osdep.h"
+#include "qemu-common.h"
#include "exec/gdbstub.h" /* xml_builtin */
+#pragma weak gdbserver_start
+
const char *const xml_builtin[][2] = {
{ NULL, NULL }
};
+
+#ifdef CONFIG_USER_ONLY
+
+int gdbserver_start(int port)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+#else
+
+int gdbserver_start(const char *device)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+#endif
diff --git a/stubs/migration.c b/stubs/migration.c
new file mode 100644
index 0000000000..28ccf80f21
--- /dev/null
+++ b/stubs/migration.c
@@ -0,0 +1,162 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "migration/misc.h"
+#include "migration/snapshot.h"
+#include "qapi/qapi-types-migration.h"
+#include "qapi/qapi-commands-migration.h"
+#include "qapi/qapi-types-net.h"
+
+MigrationInfo *qmp_query_migrate(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_migrate_set_capabilities(MigrationCapabilityStatusList *params,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+MigrationCapabilityStatusList *qmp_query_migrate_capabilities(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_migrate_set_parameters(MigrateSetParameters *params, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+MigrationParameters *qmp_query_migrate_parameters(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_migrate_start_postcopy(Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_cancel(Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_continue(MigrationStatus state, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_set_downtime(double value, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_set_speed(int64_t value, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_set_cache_size(int64_t value, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+int64_t qmp_query_migrate_cache_size(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return 0;
+}
+
+void qmp_migrate(const char *uri, bool has_blk, bool blk,
+ bool has_inc, bool inc, bool has_detach, bool detach,
+ bool has_resume, bool resume, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_incoming(const char *uri, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_recover(const char *uri, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_migrate_pause(Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_x_colo_lost_heartbeat(Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_xen_save_devices_state(const char *filename, bool has_live, bool live,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_xen_set_replication(bool enable, bool primary,
+ bool has_failover, bool failover,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+ReplicationStatus *qmp_query_xen_replication_status(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_xen_colo_do_checkpoint(Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+COLOStatus *qmp_query_colo_status(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void migration_global_dump(Monitor *mon)
+{
+ qemu_debug_assert(0);
+}
+
+int load_snapshot(const char *name, Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+int save_snapshot(const char *name, Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+AnnounceParameters *migrate_announce_params(void)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
diff --git a/stubs/monitor.c b/stubs/monitor.c
index 4613bc23e0..79c5571b2d 100644
--- a/stubs/monitor.c
+++ b/stubs/monitor.c
@@ -1,4 +1,5 @@
#include "qemu/osdep.h"
+#include "qemu-common.h"
#include "qapi/error.h"
#include "monitor/monitor.h"
#include "../monitor/monitor-internal.h"
@@ -10,6 +11,25 @@
#include "sysemu/sysemu.h"
#include "sysemu/runstate.h"
#include "monitor/hmp.h"
+#include "monitor/qdev.h"
+#include "sysemu/blockdev.h"
+#include "sysemu/sysemu.h"
+
+#include "qapi/qapi-types-block-core.h"
+#include "qapi/qapi-commands-block-core.h"
+#include "qapi/qapi-emit-events.h"
+
+#pragma weak cur_mon
+#pragma weak monitor_vprintf
+#pragma weak monitor_get_fd
+#pragma weak monitor_init
+#pragma weak qapi_event_emit
+#pragma weak monitor_get_cpu_index
+#pragma weak monitor_printf
+#pragma weak monitor_cur_is_qmp
+#pragma weak qmp_device_list_properties
+#pragma weak monitor_init_qmp
+#pragma weak monitor_init_hmp
#pragma weak hmp_handle_error
#pragma weak cur_mon
@@ -22,34 +42,45 @@ __thread Monitor *cur_mon;
int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
{
+ qemu_debug_assert(0);
abort();
}
void monitor_init_hmp(Chardev *chr, bool use_readline, Error **errp)
{
+ qemu_debug_assert(0);
}
void monitor_fdsets_cleanup(void)
{
+ qemu_debug_assert(0);
}
int monitor_get_cpu_index(void)
{
+ qemu_debug_assert(0);
+
return -ENOSYS;
}
int monitor_printf(Monitor *mon, const char *fmt, ...)
{
+ qemu_debug_assert(0);
+
return -ENOSYS;
}
bool monitor_cur_is_qmp(void)
{
+ qemu_debug_assert(0);
+
return false;
}
ObjectPropertyInfoList *qmp_device_list_properties(const char *typename,
Error **errp)
{
+ qemu_debug_assert(0);
+
return NULL;
}
diff --git a/stubs/net-stub.c b/stubs/net-stub.c
index cb2274ba40..6660e83527 100644
--- a/stubs/net-stub.c
+++ b/stubs/net-stub.c
@@ -2,6 +2,9 @@
#include "qemu-common.h"
#include "net/net.h"
+#include "qapi/qapi-commands-net.h"
+#include "qapi/qapi-commands-rocker.h"
+
int qemu_find_net_clients_except(const char *id, NetClientState **ncs,
NetClientDriver type, int max)
{
@@ -29,3 +32,69 @@ int qemu_find_nic_model(NICInfo *nd, const char * const *models,
return -ENOSYS;
}
+void qmp_set_link(const char *name, bool up, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_netdev_del(const char *id, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+RxFilterInfoList *qmp_query_rx_filter(bool has_name, const char *name,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_announce_self(AnnounceParameters *params, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+RockerSwitch *qmp_query_rocker(const char *name, Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+RockerPortList *qmp_query_rocker_ports(const char *name, Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+RockerOfDpaFlowList *qmp_query_rocker_of_dpa_flows(const char *name,
+ bool has_tbl_id,
+ uint32_t tbl_id,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+RockerOfDpaGroupList *qmp_query_rocker_of_dpa_groups(const char *name,
+ bool has_type,
+ uint8_t type,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_netdev_add(Netdev *arg, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void netdev_add(QemuOpts *opts, Error **errp)
+{
+ qemu_debug_assert(0);
+}
diff --git a/stubs/qapi-misc.c b/stubs/qapi-misc.c
new file mode 100644
index 0000000000..3eeedd997a
--- /dev/null
+++ b/stubs/qapi-misc.c
@@ -0,0 +1,41 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "qapi/qapi-commands-misc.h"
+#include "./qapi/qapi-types-dump.h"
+#include "qapi/qapi-commands-dump.h"
+
+void qmp_dump_guest_memory(bool paging, const char *file,
+ bool has_detach, bool detach,
+ bool has_begin, int64_t begin, bool has_length,
+ int64_t length, bool has_format,
+ DumpGuestMemoryFormat format, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+DumpQueryResult *qmp_query_dump(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+DumpGuestMemoryCapability *qmp_query_dump_guest_memory_capability(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_xen_load_devices_state(const char *filename, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+bool dump_in_progress(void)
+{
+ qemu_debug_assert(0);
+
+ return FALSE;
+}
diff --git a/stubs/qapi-target.c b/stubs/qapi-target.c
new file mode 100644
index 0000000000..7a16164dde
--- /dev/null
+++ b/stubs/qapi-target.c
@@ -0,0 +1,56 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "qapi/qapi-types-misc-target.h"
+#include "qapi/qapi-commands-misc-target.h"
+#include "qapi/qapi-types-machine-target.h"
+#include "qapi/qapi-commands-machine-target.h"
+
+#if defined(TARGET_I386)
+void qmp_rtc_reset_reinjection(Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+SevInfo *qmp_query_sev(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+SevLaunchMeasureInfo *qmp_query_sev_launch_measure(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+SevCapability *qmp_query_sev_capabilities(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+#endif
+
+#if defined(TARGET_S390X) || defined(TARGET_I386) || defined(TARGET_ARM)
+CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
+ CpuModelInfo *model,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+#endif
+
+#if defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_I386) || \
+ defined(TARGET_S390X) || defined(TARGET_MIPS)
+CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+#endif
diff --git a/stubs/ui-stub.c b/stubs/ui-stub.c
new file mode 100644
index 0000000000..a5a63ead50
--- /dev/null
+++ b/stubs/ui-stub.c
@@ -0,0 +1,130 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+
+#include "ui/console.h"
+#include "ui/input.h"
+#include "ui/qemu-spice.h"
+
+#include "qapi/qapi-types-ui.h"
+#include "qapi/qapi-commands-ui.h"
+
+void qmp_screendump(const char *filename, bool has_device, const char *device,
+ bool has_head, int64_t head, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+VncInfo *qmp_query_vnc(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+VncInfo2List *qmp_query_vnc_servers(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+MouseInfoList *qmp_query_mice(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_send_key(KeyValueList *keys, bool has_hold_time, int64_t hold_time,
+ Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void qmp_input_send_event(bool has_device, const char *device,
+ bool has_head, int64_t head,
+ InputEventList *events, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void vnc_display_open(const char *id, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+void vnc_display_add_client(const char *id, int csock, bool skipauth)
+{
+ qemu_debug_assert(0);
+}
+
+void qemu_input_queue_rel(QemuConsole *src, InputAxis axis, int value)
+{
+ qemu_debug_assert(0);
+}
+
+void qemu_input_queue_btn(QemuConsole *src, InputButton btn, bool down)
+{
+ qemu_debug_assert(0);
+}
+
+void qemu_input_event_sync(void)
+{
+ qemu_debug_assert(0);
+}
+
+void qemu_input_update_buttons(QemuConsole *src, uint32_t *button_map,
+ uint32_t button_old, uint32_t button_new)
+{
+ qemu_debug_assert(0);
+}
+
+#ifdef CONFIG_SPICE
+
+int using_spice;
+
+SpiceInfo *qmp_query_spice(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+int qemu_spice_migrate_info(const char *hostname, int port, int tls_port,
+ const char *subject)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+int qemu_spice_display_add_client(int csock, int skipauth, int tls)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+int qemu_spice_set_passwd(const char *passwd, bool fail_if_conn,
+ bool disconnect_if_conn)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+int qemu_spice_set_pw_expire(time_t expires)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
+
+#endif
+
+int index_from_key(const char *key, size_t key_length)
+{
+ qemu_debug_assert(0);
+
+ return -ENOSYS;
+}
diff --git a/stubs/vl-stub.c b/stubs/vl-stub.c
index fff72be201..606f078274 100644
--- a/stubs/vl-stub.c
+++ b/stubs/vl-stub.c
@@ -8,6 +8,12 @@
#include "disas/disas.h"
#include "sysemu/runstate.h"
+#include "qapi/qapi-commands-ui.h"
+#include "qapi/qapi-commands-run-state.h"
+#include "sysemu/watchdog.h"
+#include "disas/disas.h"
+#include "audio/audio.h"
+
bool tcg_allowed;
bool xen_allowed;
bool boot_strict;
@@ -21,6 +27,8 @@ int smp_threads = 1;
int icount_align_option;
int boot_menu;
+#pragma weak arch_type
+
unsigned int max_cpus;
const uint32_t arch_type;
const char *mem_path;
@@ -33,6 +41,11 @@ ram_addr_t ram_size;
MachineState *current_machine;
QemuUUID qemu_uuid;
+int singlestep;
+const char *qemu_name;
+int no_shutdown;
+int autostart;
+
int runstate_is_running(void)
{
return 0;
@@ -77,3 +90,82 @@ void x86_cpu_list(void)
{
}
#endif
+
+void qemu_system_shutdown_request(ShutdownCause reason)
+{
+ qemu_debug_assert(0);
+}
+
+void qemu_system_reset_request(ShutdownCause reason)
+{
+ qemu_debug_assert(0);
+}
+
+void qemu_system_powerdown_request(void)
+{
+ qemu_debug_assert(0);
+}
+
+void qemu_exit_preconfig_request(void)
+{
+ qemu_debug_assert(0);
+}
+
+bool runstate_needs_reset(void)
+{
+ qemu_debug_assert(0);
+
+ return FALSE;
+}
+
+bool qemu_wakeup_suspend_enabled(void)
+{
+ qemu_debug_assert(0);
+
+ return FALSE;
+}
+
+void qemu_system_wakeup_request(WakeupReason reason, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+DisplayOptions *qmp_query_display_options(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+StatusInfo *qmp_query_status(Error **errp)
+{
+ qemu_debug_assert(0);
+
+ return NULL;
+}
+
+void qmp_watchdog_set_action(WatchdogAction action, Error **errp)
+{
+ qemu_debug_assert(0);
+}
+
+int select_watchdog_action(const char *p)
+{
+ qemu_debug_assert(0);
+
+ return -1;
+}
+
+void monitor_disas(Monitor *mon, CPUState *cpu,
+ target_ulong pc, int nb_insn, int is_physical)
+{
+ qemu_debug_assert(0);
+}
+
+int wav_start_capture(AudioState *state, CaptureState *s, const char *path,
+ int freq, int bits, int nchannels)
+{
+ qemu_debug_assert(0);
+
+ return -1;
+}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 33/36] multi-process/mon: enable QMP module support in the remote process
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (31 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 32/36] multi-process/mon: stub functions to enable QMP module for remote process elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 34/36] multi-process/mon: Initialize QMP module for remote processes elena.ufimtseva
` (5 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Build system changes to enable QMP module in the remote process
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
Makefile.objs | 10 ++++++++++
Makefile.target | 35 +++++++++++++++++++++++++++++++++--
block/Makefile.objs | 3 +++
block/monitor/Makefile.objs | 2 ++
hmp-commands.hx | 1 +
hw/core/Makefile.objs | 1 +
monitor/Makefile.objs | 4 ++++
monitor/misc.c | 8 ++++++++
qapi/Makefile.objs | 2 ++
qom/Makefile.objs | 1 +
stubs/monitor.c | 1 +
ui/Makefile.objs | 2 ++
12 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index ff3f06b146..cdb55b2f82 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -32,6 +32,7 @@ remote-pci-obj-$(CONFIG_MPQEMU) += migration/
remote-pci-obj-$(CONFIG_MPQEMU) += remote/
remote-pci-obj-$(CONFIG_MPQEMU) += accel/
remote-pci-obj-$(CONFIG_MPQEMU) += util/
+remote-pci-obj-$(CONFIG_MPQEMU) += monitor/
remote-pci-obj-$(CONFIG_MPQEMU) += cpus-common.o
remote-pci-obj-$(CONFIG_MPQEMU) += dma-helpers.o
@@ -45,6 +46,10 @@ remote-pci-obj-$(CONFIG_MPQEMU) += qemu-parse.o
# remote-lsi-obj-y is code used to implement remote LSI device
remote-lsi-obj-$(CONFIG_MPQEMU) += hw/
+remote-lsi-obj-$(CONFIG_MPQEMU) += ui/
+remote-lsi-obj-$(CONFIG_MPQEMU) += block/
+
+#remote-lsi-obj-$(CONFIG_MPQEMU) += device-hotplug.o
#######################################################################
# crypto-obj-y is code used by both qemu system emulation and qemu-img
@@ -113,6 +118,11 @@ common-obj-y += util/machine-notify.o
endif # CONFIG_SOFTMMU
+remote-pci-obj-$(CONFIG_MPQEMU) += qapi/
+remote-pci-obj-$(CONFIG_MPQEMU) += blockdev-nbd.o
+remote-pci-obj-$(CONFIG_MPQEMU) += job-qmp.o
+remote-pci-obj-$(CONFIG_MPQEMU) += balloon.o
+
#######################################################################
# Target-independent parts used in system and user emulation
common-obj-y += cpus-common.o
diff --git a/Makefile.target b/Makefile.target
index adc76886f8..1e9e102df8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -142,13 +142,32 @@ remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/hax-stub.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/whpx-stub.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/vl-stub.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/net-stub.o
-remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/monitor.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/replay.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/xen-mapcache.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/audio.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/monitor.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/migration.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/ui-stub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/gdbstub.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/qapi-target.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/qapi-misc.o
remote-pci-tgt-obj-$(CONFIG_MPQEMU) += remote/memory.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += arch_init.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += monitor/misc.o
+
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-introspect.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-commands-block-core.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-commands-block.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-commands-misc.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-commands.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-commands-machine-target.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-commands-misc-target.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-visit-machine-target.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-visit-misc-target.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-types-machine-target.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-types-misc-target.o
+remote-pci-tgt-obj-$(CONFIG_MPQEMU) += qapi/qapi-init-commands.o
endif
#########################################################
@@ -204,6 +223,10 @@ endif
generated-files-y += hmp-commands.h hmp-commands-info.h
generated-files-y += config-devices.h
+ifdef CONFIG_MPQEMU
+generated-files-y += hmp-scsi-commands.h hmp-scsi-commands-info.h
+endif
+
endif # CONFIG_SOFTMMU
dummy := $(call unnest-vars,,obj-y)
@@ -289,10 +312,18 @@ hmp-commands.h: $(SRC_PATH)/hmp-commands.hx $(SRC_PATH)/scripts/hxtool
hmp-commands-info.h: $(SRC_PATH)/hmp-commands-info.hx $(SRC_PATH)/scripts/hxtool
$(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > $@,"GEN","$(TARGET_DIR)$@")
+ifdef CONFIG_MPQEMU
+hmp-scsi-commands.h: $(SRC_PATH)/hmp-commands.hx $(SRC_PATH)/scripts/hxtool
+ $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -tgt scsi < $< > $@)
+
+hmp-scsi-commands-info.h: $(SRC_PATH)/hmp-commands-info.hx $(SRC_PATH)/scripts/hxtool
+ $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -tgt scsi < $< > $@)
+endif
+
clean: clean-target
rm -f *.a *~ $(PROGS)
rm -f $(shell find . -name '*.[od]')
- rm -f hmp-commands.h gdbstub-xml.c
+ rm -f hmp-commands.h gdbstub-xml.c hmp-scsi-commands.h hmp-scsi-commands-info.h
rm -f trace/generated-helpers.c trace/generated-helpers.c-timestamp
ifdef CONFIG_TRACE_SYSTEMTAP
rm -f *.stp
diff --git a/block/Makefile.objs b/block/Makefile.objs
index 3e7513967c..734548d48f 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -76,3 +76,6 @@ parallels.o-cflags := $(LIBXML2_CFLAGS)
parallels.o-libs := $(LIBXML2_LIBS)
remote-pci-obj-$(CONFIG_MPQEMU) += stream.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qapi-sysemu.o
+
+remote-lsi-obj-$(CONFIG_MPQEMU) += monitor/
diff --git a/block/monitor/Makefile.objs b/block/monitor/Makefile.objs
index 0a74f9a8b5..a0c898711f 100644
--- a/block/monitor/Makefile.objs
+++ b/block/monitor/Makefile.objs
@@ -1 +1,3 @@
common-obj-y += block-hmp-cmds.o
+
+remote-lsi-obj-$(CONFIG_MPQEMU) += block-hmp-cmds.o
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 1b60676d7c..54d01a055f 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -12,6 +12,7 @@ HXCOMM HXCOMM can be used for comments, discarded from both rST and C.
.params = "[cmd]",
.help = "show the help",
.cmd = hmp_do_help_cmd,
+ .targets = "scsi",
.flags = "p",
},
diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
index e3e80848c8..251b77bc4c 100644
--- a/hw/core/Makefile.objs
+++ b/hw/core/Makefile.objs
@@ -49,3 +49,4 @@ remote-pci-obj-$(CONFIG_MPQEMU) += numa.o
remote-pci-obj-$(CONFIG_MPQEMU) += cpu.o
remote-pci-obj-$(CONFIG_MPQEMU) += vmstate-if.o
remote-pci-obj-$(CONFIG_MPQEMU) += resettable.o
+remote-pci-obj-$(CONFIG_MPQEMU) += machine-qmp-cmds.o
diff --git a/monitor/Makefile.objs b/monitor/Makefile.objs
index a8533c9dd7..b6949be297 100644
--- a/monitor/Makefile.objs
+++ b/monitor/Makefile.objs
@@ -4,3 +4,7 @@ common-obj-y += qmp-cmds.o qmp-cmds-control.o
common-obj-y += hmp-cmds.o
storage-daemon-obj-y += monitor.o qmp.o qmp-cmds-control.o
+
+remote-pci-obj-$(CONFIG_MPQEMU) += monitor.o qmp.o hmp.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qmp-cmds.o qmp-cmds-control.o
+remote-pci-obj-$(CONFIG_MPQEMU) += hmp-cmds.o
diff --git a/monitor/misc.c b/monitor/misc.c
index c0eee6f4ab..edda4cce17 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -1679,13 +1679,21 @@ int monitor_fd_param(Monitor *mon, const char *fdname, Error **errp)
/* Please update hmp-commands.hx when adding or changing commands */
static HMPCommand hmp_info_cmds[] = {
+#if defined(SCSI_PROCESS)
+#include "hmp-scsi-commands-info.h"
+#else
#include "hmp-commands-info.h"
+#endif
{ NULL, NULL, },
};
/* hmp_cmds and hmp_info_cmds would be sorted at runtime */
HMPCommand hmp_cmds[] = {
+#if defined(SCSI_PROCESS)
+#include "hmp-scsi-commands.h"
+#else
#include "hmp-commands.h"
+#endif
{ NULL, NULL, },
};
diff --git a/qapi/Makefile.objs b/qapi/Makefile.objs
index 4673ab7490..f7433d6a73 100644
--- a/qapi/Makefile.objs
+++ b/qapi/Makefile.objs
@@ -36,3 +36,5 @@ QAPI_MODULES_STORAGE_DAEMON = block-core char common control crypto
QAPI_MODULES_STORAGE_DAEMON += introspect job qom sockets pragma transaction
storage-daemon-obj-y += $(QAPI_MODULES_STORAGE_DAEMON:%=qapi-commands-%.o)
+
+remote-pci-obj-$(CONFIG_MPQEMU) += $(QAPI_COMMON_MODULES:%=qapi-commands-%.o)
diff --git a/qom/Makefile.objs b/qom/Makefile.objs
index 7e9455db90..546f9fbde6 100644
--- a/qom/Makefile.objs
+++ b/qom/Makefile.objs
@@ -6,3 +6,4 @@ storage-daemon-obj-y += qom-qmp-cmds.o
remote-pci-obj-$(CONFIG_MPQEMU) += object.o qom-qobject.o container.o
remote-pci-obj-$(CONFIG_MPQEMU) += object_interfaces.o
+remote-pci-obj-$(CONFIG_MPQEMU) += qom-qmp-cmds.o qom-hmp-cmds.o
diff --git a/stubs/monitor.c b/stubs/monitor.c
index 79c5571b2d..b845a95d5c 100644
--- a/stubs/monitor.c
+++ b/stubs/monitor.c
@@ -37,6 +37,7 @@
#pragma weak monitor_printf
#pragma weak monitor_cur_is_qmp
#pragma weak qmp_device_list_properties
+#pragma weak monitor_fdsets_cleanup
__thread Monitor *cur_mon;
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index e6da6ff047..c3ac572d6b 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -68,3 +68,5 @@ console-gl.o-libs += $(OPENGL_LIBS)
egl-helpers.o-libs += $(OPENGL_LIBS)
egl-context.o-libs += $(OPENGL_LIBS)
egl-headless.o-libs += $(OPENGL_LIBS)
+
+remote-lsi-obj-$(CONFIG_MPQEMU) += vnc-stubs.o
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 34/36] multi-process/mon: Initialize QMP module for remote processes
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (32 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 33/36] multi-process/mon: enable QMP module support in the " elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 35/36] multi-process: add the concept description to docs/devel/qemu-multiprocess elena.ufimtseva
` (4 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
remote/remote-main.c | 13 +++++++++++++
remote/remote-opts.c | 11 +++++++++++
2 files changed, 24 insertions(+)
diff --git a/remote/remote-main.c b/remote/remote-main.c
index 562db4ccc3..199af144dd 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -40,6 +40,9 @@
#include "remote/iohub.h"
#include "remote-opts.h"
#include "sysemu/reset.h"
+#include "qemu-parse.h"
+#include "monitor/monitor.h"
+#include "chardev/char.h"
static void process_msg(GIOCondition cond, MPQemuLinkState *link,
MPQemuChannel *chan);
@@ -313,6 +316,8 @@ int main(int argc, char *argv[])
module_call_init(MODULE_INIT_QOM);
+ monitor_init_globals();
+
bdrv_init_with_whitelist();
if (qemu_init_main_loop(&err)) {
@@ -330,6 +335,8 @@ int main(int argc, char *argv[])
qemu_add_opts(&qemu_device_opts);
qemu_add_opts(&qemu_drive_opts);
+ qemu_add_opts(&qemu_chardev_opts);
+ qemu_add_opts(&qemu_mon_opts);
qemu_add_drive_opts(&qemu_legacy_drive_opts);
qemu_add_drive_opts(&qemu_common_drive_opts);
qemu_add_drive_opts(&qemu_drive_opts);
@@ -351,6 +358,12 @@ int main(int argc, char *argv[])
parse_cmdline(argc - 2, argv + 2, NULL);
+ qemu_opts_foreach(qemu_find_opts("chardev"),
+ chardev_init_func, NULL, &error_fatal);
+
+ qemu_opts_foreach(qemu_find_opts("mon"),
+ mon_init_func, NULL, &error_fatal);
+
mpqemu_init_channel(mpqemu_link, &mpqemu_link->com, fd);
mpqemu_link_set_callback(mpqemu_link, process_msg);
diff --git a/remote/remote-opts.c b/remote/remote-opts.c
index f077221c71..ac3a9be6b8 100644
--- a/remote/remote-opts.c
+++ b/remote/remote-opts.c
@@ -15,6 +15,7 @@
#include "qemu-options.h"
#include "qemu-parse.h"
#include "remote-opts.h"
+#include "monitor/monitor.h"
/*
* In remote process, we parse only subset of options. The code
@@ -64,6 +65,16 @@ void parse_cmdline(int argc, char **argv, char **envp)
exit(1);
}
break;
+ case QEMU_OPTION_qmp:
+ monitor_parse(optarg, "control", false);
+ break;
+ case QEMU_OPTION_monitor:
+ if (!strncmp(optarg, "stdio", 5)) {
+ warn_report("STDIO not supported in remote process");
+ } else if (strncmp(optarg, "none", 4)) {
+ monitor_parse(optarg, "readline", false);
+ }
+ break;
default:
break;
}
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 35/36] multi-process: add the concept description to docs/devel/qemu-multiprocess
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (33 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 34/36] multi-process/mon: Initialize QMP module for remote processes elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 36/36] multi-process: add configure and usage information elena.ufimtseva
` (3 subsequent siblings)
38 siblings, 0 replies; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
MAINTAINERS | 1 +
docs/devel/index.rst | 1 +
docs/devel/multi-process.rst | 957 +++++++++++++++++++++++++++++++++++
3 files changed, 959 insertions(+)
create mode 100644 docs/devel/multi-process.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index 216291f545..ed48615e15 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2879,6 +2879,7 @@ F: include/remote/iohub.h
F: remote/iohub.c
F: remote/remote-opts.h
F: remote/remote-opts.c
+F: docs/devel/multi-process.rst
Build and test automation
-------------------------
diff --git a/docs/devel/index.rst b/docs/devel/index.rst
index a9e1200dff..95cea0d474 100644
--- a/docs/devel/index.rst
+++ b/docs/devel/index.rst
@@ -27,3 +27,4 @@ Contents:
bitops
reset
s390-dasd-ipl
+ multi-process
diff --git a/docs/devel/multi-process.rst b/docs/devel/multi-process.rst
new file mode 100644
index 0000000000..406728854c
--- /dev/null
+++ b/docs/devel/multi-process.rst
@@ -0,0 +1,957 @@
+Multi-process QEMU
+===================
+
+QEMU is often used as the hypervisor for virtual machines running in the
+Oracle cloud. Since one of the advantages of cloud computing is the
+ability to run many VMs from different tenants in the same cloud
+infrastructure, a guest that compromised its hypervisor could
+potentially use the hypervisor's access privileges to access data it is
+not authorized for.
+
+QEMU can be susceptible to security attacks because it is a large,
+monolithic program that provides many features to the VMs it services.
+Many of these features can be configured out of QEMU, but even a reduced
+configuration QEMU has a large amount of code a guest can potentially
+attack. Separating QEMU reduces the attack surface by aiding to
+limit each component in the system to only access the resources that
+it needs to perform its job.
+
+QEMU services
+-------------
+
+QEMU can be broadly described as providing three main services. One is a
+VM control point, where VMs can be created, migrated, re-configured, and
+destroyed. A second is to emulate the CPU instructions within the VM,
+often accelerated by HW virtualization features such as Intel's VT
+extensions. Finally, it provides IO services to the VM by emulating HW
+IO devices, such as disk and network devices.
+
+A multi-process QEMU
+~~~~~~~~~~~~~~~~~~~~
+
+A multi-process QEMU involves separating QEMU services into separate
+host processes. Each of these processes can be given only the privileges
+it needs to provide its service, e.g., a disk service could be given
+access only to the disk images it provides, and not be allowed to
+access other files, or any network devices. An attacker who compromised
+this service would not be able to use this exploit to access files or
+devices beyond what the disk service was given access to.
+
+A QEMU control process would remain, but in multi-process mode, will
+have no direct interfaces to the VM. During VM execution, it would still
+provide the user interface to hot-plug devices or live migrate the VM.
+
+A first step in creating a multi-process QEMU is to separate IO services
+from the main QEMU program, which would continue to provide CPU
+emulation. i.e., the control process would also be the CPU emulation
+process. In a later phase, CPU emulation could be separated from the
+control process.
+
+Separating IO services
+----------------------
+
+Separating IO services into individual host processes is a good place to
+begin for a couple of reasons. One is the sheer number of IO devices QEMU
+can emulate provides a large surface of interfaces which could potentially
+be exploited, and, indeed, have been a source of exploits in the past.
+Another is the modular nature of QEMU device emulation code provides
+interface points where the QEMU functions that perform device emulation
+can be separated from the QEMU functions that manage the emulation of
+guest CPU instructions. The devices emulated in the separate process are
+referred to as remote devices.
+
+QEMU device emulation
+~~~~~~~~~~~~~~~~~~~~~
+
+QEMU uses an object oriented SW architecture for device emulation code.
+Configured objects are all compiled into the QEMU binary, then objects
+are instantiated by name when used by the guest VM. For example, the
+code to emulate a device named "foo" is always present in QEMU, but its
+instantiation code is only run when the device is included in the target
+VM. (e.g., via the QEMU command line as *-device foo*)
+
+The object model is hierarchical, so device emulation code names its
+parent object (such as "pci-device" for a PCI device) and QEMU will
+instantiate a parent object before calling the device's instantiation
+code.
+
+Current separation models
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to separate the device emulation code from the CPU emulation
+code, the device object code must run in a different process. There are
+a couple of existing QEMU features that can run emulation code
+separately from the main QEMU process. These are examined below.
+
+vhost user model
+^^^^^^^^^^^^^^^^
+
+Virtio guest device drivers can be connected to vhost user applications
+in order to perform their IO operations. This model uses special virtio
+device drivers in the guest and vhost user device objects in QEMU, but
+once the QEMU vhost user code has configured the vhost user application,
+mission-mode IO is performed by the application. The vhost user
+application is a daemon process that can be contacted via a known UNIX
+domain socket.
+
+vhost socket
+''''''''''''
+
+As mentioned above, one of the tasks of the vhost device object within
+QEMU is to contact the vhost application and send it configuration
+information about this device instance. As part of the configuration
+process, the application can also be sent other file descriptors over
+the socket, which then can be used by the vhost user application in
+various ways, some of which are described below.
+
+vhost MMIO store acceleration
+'''''''''''''''''''''''''''''
+
+VMs are often run using HW virtualization features via the KVM kernel
+driver. This driver allows QEMU to accelerate the emulation of guest CPU
+instructions by running the guest in a virtual HW mode. When the guest
+executes instructions that cannot be executed by virtual HW mode,
+execution returns to the KVM driver so it can inform QEMU to emulate the
+instructions in SW.
+
+One of the events that can cause a return to QEMU is when a guest device
+driver accesses an IO location. QEMU then dispatches the memory
+operation to the corresponding QEMU device object. In the case of a
+vhost user device, the memory operation would need to be sent over a
+socket to the vhost application. This path is accelerated by the QEMU
+virtio code by setting up an eventfd file descriptor that the vhost
+application can directly receive MMIO store notifications from the KVM
+driver, instead of needing them to be sent to the QEMU process first.
+
+vhost interrupt acceleration
+''''''''''''''''''''''''''''
+
+Another optimization used by the vhost application is the ability to
+directly inject interrupts into the VM via the KVM driver, again,
+bypassing the need to send the interrupt back to the QEMU process first.
+The QEMU virtio setup code configures the KVM driver with an eventfd
+that triggers the device interrupt in the guest when the eventfd is
+written. This irqfd file descriptor is then passed to the vhost user
+application program.
+
+vhost access to guest memory
+''''''''''''''''''''''''''''
+
+The vhost application is also allowed to directly access guest memory,
+instead of needing to send the data as messages to QEMU. This is also
+done with file descriptors sent to the vhost user application by QEMU.
+These descriptors can be passed to ``mmap()`` by the vhost application
+to map the guest address space into the vhost application.
+
+IOMMUs introduce another level of complexity, since the address given to
+the guest virtio device to DMA to or from is not a guest physical
+address. This case is handled by having vhost code within QEMU register
+as a listener for IOMMU mapping changes. The vhost application maintains
+a cache of IOMMMU translations: sending translation requests back to
+QEMU on cache misses, and in turn receiving flush requests from QEMU
+when mappings are purged.
+
+applicability to device separation
+''''''''''''''''''''''''''''''''''
+
+Much of the vhost model can be re-used by separated device emulation. In
+particular, the ideas of using a socket between QEMU and the device
+emulation application, using a file descriptor to inject interrupts into
+the VM via KVM, and allowing the application to ``mmap()`` the guest
+should be re used.
+
+There are, however, some notable differences between how a vhost
+application works and the needs of separated device emulation. The most
+basic is that vhost uses custom virtio device drivers which always
+trigger IO with MMIO stores. A separated device emulation model must
+work with existing IO device models and guest device drivers. MMIO loads
+break vhost store acceleration since they are synchronous - guest
+progress cannot continue until the load has been emulated. By contrast,
+stores are asynchronous, the guest can continue after the store event
+has been sent to the vhost application.
+
+Another difference is that in the vhost user model, a single daemon can
+support multiple QEMU instances. This is contrary to the security regime
+desired, in which the emulation application should only be allowed to
+access the files or devices the VM it's running on behalf of can access.
+#### qemu-io model
+
+Qemu-io is a test harness used to test changes to the QEMU block backend
+object code. (e.g., the code that implements disk images for disk driver
+emulation) Qemu-io is not a device emulation application per se, but it
+does compile the QEMU block objects into a separate binary from the main
+QEMU one. This could be useful for disk device emulation, since its
+emulation applications will need to include the QEMU block objects.
+
+New separation model based on proxy objects
+-------------------------------------------
+
+A different model based on proxy objects in the QEMU program
+communicating with remote emulation programs could provide separation
+while minimizing the changes needed to the device emulation code. The
+rest of this section is a discussion of how a proxy object model would
+work.
+
+Remote emulation processes
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The remote emulation process will run the QEMU object hierarchy without
+modification. The device emulation objects will be also be based on the
+QEMU code, because for anything but the simplest device, it would not be
+a tractable to re-implement both the object model and the many device
+backends that QEMU has.
+
+The processes will communicate with the QEMU process over UNIX domain
+sockets. The processes can be executed either as standalone processes,
+or be executed by QEMU. In both cases, the host backends the emulation
+processes will provide are specified on its command line, as they would
+be for QEMU. For example:
+
+::
+
+ disk-proc -blockdev driver=file,node-name=file0,filename=disk-file0 \
+ -blockdev driver=qcow2,node-name=drive0,file=file0
+
+would indicate process *disk-proc* uses a qcow2 emulated disk named
+*file0* as its backend.
+
+Emulation processes may emulate more than one guest controller. A common
+configuration might be to put all controllers of the same device class
+(e.g., disk, network, etc.) in a single process, so that all backends of
+the same type can be managed by a single QMP monitor.
+
+communication with QEMU
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The first argument to the remote emulation process will be a Unix domain
+socket that connects with the Proxy object. This is a required argument.
+
+::
+
+ disk-proc <socket number> <backend list>
+
+remote process QMP monitor
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Remote emulation processes can be monitored via QMP, similar to QEMU
+itself. The QMP monitor socket is specified the same as for a QEMU
+process:
+
+::
+
+ disk-proc -qmp unix:/tmp/disk-mon,server
+
+can be monitored over the UNIX socket path */tmp/disk-mon*.
+
+QEMU command line
+~~~~~~~~~~~~~~~~~
+
+Each remote device emulated in a remote process on the host is
+represented as a *-device* of type *pci-proxy-dev*. A socket
+sub-option to this option specifies the Unix socket that connects
+to the remote process. An *id* sub-option is required, and it should
+be the same id as used in the remote process.
+
+::
+
+ qemu-system-x86_64 ... -device pci-proxy-dev,id=lsi0,socket=3
+
+can be used to add a device emulated in a remote process
+
+
+QEMU management of remote processes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+QEMU is not aware of the type of type of the remote PCI device. It is
+a pass through device as far as QEMU is concerned.
+
+communication with emulation process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+primary channel
+'''''''''''''''
+
+The primary channel (referred to as com in the code) is used to bootstrap
+the remote process. It is also used to pass on device-agnostic commands
+like reset.
+
+per-device channels
+'''''''''''''''''''
+
+Each remote device communicates with QEMU using a dedicated communication
+channel. The proxy object sets up this channel using the primary
+channel during its initialization.
+
+QEMU device proxy objects
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+QEMU has an object model based on sub-classes inherited from the
+"object" super-class. The sub-classes that are of interest here are the
+"device" and "bus" sub-classes whose child sub-classes make up the
+device tree of a QEMU emulated system.
+
+The proxy object model will use device proxy objects to replace the
+device emulation code within the QEMU process. These objects will live
+in the same place in the object and bus hierarchies as the objects they
+replace. i.e., the proxy object for an LSI SCSI controller will be a
+sub-class of the "pci-device" class, and will have the same PCI bus
+parent and the same SCSI bus child objects as the LSI controller object
+it replaces.
+
+It is worth noting that the same proxy object is used to mediate with
+all types of remote PCI devices.
+
+object initialization
+^^^^^^^^^^^^^^^^^^^^^
+
+The Proxy device objects are initialized in the exact same manner in
+which any other QEMU device would be initialized.
+
+In addition, the Proxy objects perform the following two tasks:
+- Parses the "socket" sub option and connects to the remote process
+using this channel
+- Uses the "id" sub-option to connect to the emulated device on the
+separate process
+
+class\_init
+'''''''''''
+
+The ``class_init()`` method of a proxy object will, in general behave
+similarly to the object it replaces, including setting any static
+properties and methods needed by the proxy.
+
+instance\_init / realize
+''''''''''''''''''''''''
+
+The ``instance_init()`` and ``realize()`` functions would only need to
+perform tasks related to being a proxy, such are registering its own
+MMIO handlers, or creating a child bus that other proxy devices can be
+attached to later.
+
+Other tasks will be device-specific. For example, PCI device objects
+will initialize the PCI config space in order to make a valid PCI device
+tree within the QEMU process.
+
+address space registration
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most devices are driven by guest device driver accesses to IO addresses
+or ports. The QEMU device emulation code uses QEMU's memory region
+function calls (such as ``memory_region_init_io()``) to add callback
+functions that QEMU will invoke when the guest accesses the device's
+areas of the IO address space. When a guest driver does access the
+device, the VM will exit HW virtualization mode and return to QEMU,
+which will then lookup and execute the corresponding callback function.
+
+A proxy object would need to mirror the memory region calls the actual
+device emulator would perform in its initialization code, but with its
+own callbacks. When invoked by QEMU as a result of a guest IO operation,
+they will forward the operation to the device emulation process.
+
+PCI config space
+^^^^^^^^^^^^^^^^
+
+PCI devices also have a configuration space that can be accessed by the
+guest driver. Guest accesses to this space is not handled by the device
+emulation object, but by its PCI parent object. Much of this space is
+read-only, but certain registers (especially BAR and MSI-related ones)
+need to be propagated to the emulation process.
+
+PCI parent proxy
+''''''''''''''''
+
+One way to propagate guest PCI config accesses is to create a
+"pci-device-proxy" class that can serve as the parent of a PCI device
+proxy object. This class's parent would be "pci-device" and it would
+override the PCI parent's ``config_read()`` and ``config_write()``
+methods with ones that forward these operations to the emulation
+program.
+
+interrupt receipt
+^^^^^^^^^^^^^^^^^
+
+A proxy for a device that generates interrupts will need to create a
+socket to receive interrupt indications from the emulation process. An
+incoming interrupt indication would then be sent up to its bus parent to
+be injected into the guest. For example, a PCI device object may use
+``pci_set_irq()``.
+
+live migration
+^^^^^^^^^^^^^^
+
+The proxy will register to save and restore any *vmstate* it needs over
+a live migration event. The device proxy does not need to manage the
+remote device's *vmstate*; that will be handled by the remote process
+proxy (see below).
+
+QEMU remote device operation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Generic device operations, such as DMA, will be performed by the remote
+process proxy by sending messages to the remote process.
+
+DMA operations
+^^^^^^^^^^^^^^
+
+DMA operations would be handled much like vhost applications do. One of
+the initial messages sent to the emulation process is a guest memory
+table. Each entry in this table consists of a file descriptor and size
+that the emulation process can ``mmap()`` to directly access guest
+memory, similar to ``vhost_user_set_mem_table()``. Note guest memory
+must be backed by file descriptors, such as when QEMU is given the
+*-mem-path* command line option.
+
+IOMMU operations
+^^^^^^^^^^^^^^^^
+
+When the emulated system includes an IOMMU, the remote process proxy in
+QEMU will need to create a socket for IOMMU requests from the emulation
+process. It will handle those requests with an
+``address_space_get_iotlb_entry()`` call. In order to handle IOMMU
+unmaps, the remote process proxy will also register as a listener on the
+device's DMA address space. When an IOMMU memory region is created
+within the DMA address space, an IOMMU notifier for unmaps will be added
+to the memory region that will forward unmaps to the emulation process
+over the IOMMU socket.
+
+device hot-plug via QMP
+^^^^^^^^^^^^^^^^^^^^^^^
+
+An QMP "device\_add" command can add a device emulated by a remote
+process. It will also have "rid" option to the command, just as the
+*-device* command line option does. The remote process may either be one
+started at QEMU startup, or be one added by the "add-process" QMP
+command described above. In either case, the remote process proxy will
+forward the new device's JSON description to the corresponding emulation
+process.
+
+live migration
+^^^^^^^^^^^^^^
+
+The remote process proxy will also register for live migration
+notifications with ``vmstate_register()``. When called to save state,
+the proxy will send the remote process a secondary socket file
+descriptor to save the remote process's device *vmstate* over. The
+incoming byte stream length and data will be saved as the proxy's
+*vmstate*. When the proxy is resumed on its new host, this *vmstate*
+will be extracted, and a secondary socket file descriptor will be sent
+to the new remote process through which it receives the *vmstate* in
+order to restore the devices there.
+
+device emulation in remote process
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The parts of QEMU that the emulation program will need include the
+object model; the memory emulation objects; the device emulation objects
+of the targeted device, and any dependent devices; and, the device's
+backends. It will also need code to setup the machine environment,
+handle requests from the QEMU process, and route machine-level requests
+(such as interrupts or IOMMU mappings) back to the QEMU process.
+
+initialization
+^^^^^^^^^^^^^^
+
+The process initialization sequence will follow the same sequence
+followed by QEMU. It will first initialize the backend objects, then
+device emulation objects. The JSON descriptions sent by the QEMU process
+will drive which objects need to be created.
+
+- address spaces
+
+Before the device objects are created, the initial address spaces and
+memory regions must be configured with ``memory_map_init()``. This
+creates a RAM memory region object (*system\_memory*) and an IO memory
+region object (*system\_io*).
+
+- RAM
+
+RAM memory region creation will follow how ``pc_memory_init()`` creates
+them, but must use ``memory_region_init_ram_from_fd()`` instead of
+``memory_region_allocate_system_memory()``. The file descriptors needed
+will be supplied by the guest memory table from above. Those RAM regions
+would then be added to the *system\_memory* memory region with
+``memory_region_add_subregion()``.
+
+- PCI
+
+IO initialization will be driven by the JSON descriptions sent from the
+QEMU process. For a PCI device, a PCI bus will need to be created with
+``pci_root_bus_new()``, and a PCI memory region will need to be created
+and added to the *system\_memory* memory region with
+``memory_region_add_subregion_overlap()``. The overlap version is
+required for architectures where PCI memory overlaps with RAM memory.
+
+MMIO handling
+^^^^^^^^^^^^^
+
+The device emulation objects will use ``memory_region_init_io()`` to
+install their MMIO handlers, and ``pci_register_bar()`` to associate
+those handlers with a PCI BAR, as they do within QEMU currently.
+
+In order to use ``address_space_rw()`` in the emulation process to
+handle MMIO requests from QEMU, the PCI physical addresses must be the
+same in the QEMU process and the device emulation process. In order to
+accomplish that, guest BAR programming must also be forwarded from QEMU
+to the emulation process.
+
+interrupt injection
+^^^^^^^^^^^^^^^^^^^
+
+When device emulation wants to inject an interrupt into the VM, the
+request climbs the device's bus object hierarchy until the point where a
+bus object knows how to signal the interrupt to the guest. The details
+depend on the type of interrupt being raised.
+
+- PCI pin interrupts
+
+On x86 systems, there is an emulated IOAPIC object attached to the root
+PCI bus object, and the root PCI object forwards interrupt requests to
+it. The IOAPIC object, in turn, calls the KVM driver to inject the
+corresponding interrupt into the VM. The simplest way to handle this in
+an emulation process would be to setup the root PCI bus driver (via
+``pci_bus_irqs()``) to send a interrupt request back to the QEMU
+process, and have the device proxy object reflect it up the PCI tree
+there.
+
+- PCI MSI/X interrupts
+
+PCI MSI/X interrupts are implemented in HW as DMA writes to a
+CPU-specific PCI address. In QEMU on x86, a KVM APIC object receives
+these DMA writes, then calls into the KVM driver to inject the interrupt
+into the VM. A simple emulation process implementation would be to send
+the MSI DMA address from QEMU as a message at initialization, then
+install an address space handler at that address which forwards the MSI
+message back to QEMU.
+
+DMA operations
+^^^^^^^^^^^^^^
+
+When a emulation object wants to DMA into or out of guest memory, it
+first must use dma\_memory\_map() to convert the DMA address to a local
+virtual address. The emulation process memory region objects setup above
+will be used to translate the DMA address to a local virtual address the
+device emulation code can access.
+
+IOMMU
+^^^^^
+
+When an IOMMU is in use in QEMU, DMA translation uses IOMMU memory
+regions to translate the DMA address to a guest physical address before
+that physical address can be translated to a local virtual address. The
+emulation process will need similar functionality.
+
+- IOTLB cache
+
+The emulation process will maintain a cache of recent IOMMU translations
+(the IOTLB). When the translate() callback of an IOMMU memory region is
+invoked, the IOTLB cache will be searched for an entry that will map the
+DMA address to a guest PA. On a cache miss, a message will be sent back
+to QEMU requesting the corresponding translation entry, which be both be
+used to return a guest address and be added to the cache.
+
+- IOTLB purge
+
+The IOMMU emulation will also need to act on unmap requests from QEMU.
+These happen when the guest IOMMU driver purges an entry from the
+guest's translation table.
+
+live migration
+^^^^^^^^^^^^^^
+
+When a remote process receives a live migration indication from QEMU, it
+will set up a channel using the received file descriptor with
+``qio_channel_socket_new_fd()``. This channel will be used to create a
+*QEMUfile* that can be passed to ``qemu_save_device_state()`` to send
+the process's device state back to QEMU. This method will be reversed on
+restore - the channel will be passed to ``qemu_loadvm_state()`` to
+restore the device state.
+
+Accelerating device emulation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The messages that are required to be sent between QEMU and the emulation
+process can add considerable latency to IO operations. The optimizations
+described below attempt to ameliorate this effect by allowing the
+emulation process to communicate directly with the kernel KVM driver.
+The KVM file descriptors created would be passed to the emulation process
+via initialization messages, much like the guest memory table is done.
+#### MMIO acceleration
+
+Vhost user applications can receive guest virtio driver stores directly
+from KVM. The issue with the eventfd mechanism used by vhost user is
+that it does not pass any data with the event indication, so it cannot
+handle guest loads or guest stores that carry store data. This concept
+could, however, be expanded to cover more cases.
+
+The expanded idea would require a new type of KVM device:
+*KVM\_DEV\_TYPE\_USER*. This device has two file descriptors: a master
+descriptor that QEMU can use for configuration, and a slave descriptor
+that the emulation process can use to receive MMIO notifications. QEMU
+would create both descriptors using the KVM driver, and pass the slave
+descriptor to the emulation process via an initialization message.
+
+data structures
+^^^^^^^^^^^^^^^
+
+- guest physical range
+
+The guest physical range structure describes the address range that a
+device will respond to. It includes the base and length of the range, as
+well as which bus the range resides on (e.g., on an x86machine, it can
+specify whether the range refers to memory or IO addresses).
+
+A device can have multiple physical address ranges it responds to (e.g.,
+a PCI device can have multiple BARs), so the structure will also include
+an enumerated identifier to specify which of the device's ranges is
+being referred to.
+
++--------+----------------------------+
+| Name | Description |
++========+============================+
+| addr | range base address |
++--------+----------------------------+
+| len | range length |
++--------+----------------------------+
+| bus | addr type (memory or IO) |
++--------+----------------------------+
+| id | range ID (e.g., PCI BAR) |
++--------+----------------------------+
+
+- MMIO request structure
+
+This structure describes an MMIO operation. It includes which guest
+physical range the MMIO was within, the offset within that range, the
+MMIO type (e.g., load or store), and its length and data. It also
+includes a sequence number that can be used to reply to the MMIO, and
+the CPU that issued the MMIO.
+
++----------+------------------------+
+| Name | Description |
++==========+========================+
+| rid | range MMIO is within |
++----------+------------------------+
+| offset | offset withing *rid* |
++----------+------------------------+
+| type | e.g., load or store |
++----------+------------------------+
+| len | MMIO length |
++----------+------------------------+
+| data | store data |
++----------+------------------------+
+| seq | sequence ID |
++----------+------------------------+
+
+- MMIO request queues
+
+MMIO request queues are FIFO arrays of MMIO request structures. There
+are two queues: pending queue is for MMIOs that haven't been read by the
+emulation program, and the sent queue is for MMIOs that haven't been
+acknowledged. The main use of the second queue is to validate MMIO
+replies from the emulation program.
+
+- scoreboard
+
+Each CPU in the VM is emulated in QEMU by a separate thread, so multiple
+MMIOs may be waiting to be consumed by an emulation program and multiple
+threads may be waiting for MMIO replies. The scoreboard would contain a
+wait queue and sequence number for the per-CPU threads, allowing them to
+be individually woken when the MMIO reply is received from the emulation
+program. It also tracks the number of posted MMIO stores to the device
+that haven't been replied to, in order to satisfy the PCI constraint
+that a load to a device will not complete until all previous stores to
+that device have been completed.
+
+- device shadow memory
+
+Some MMIO loads do not have device side-effects. These MMIOs can be
+completed without sending a MMIO request to the emulation program if the
+emulation program shares a shadow image of the device's memory image
+with the KVM driver.
+
+The emulation program will ask the KVM driver to allocate memory for the
+shadow image, and will then use ``mmap()`` to directly access it. The
+emulation program can control KVM access to the shadow image by sending
+KVM an access map telling it which areas of the image have no
+side-effects (and can be completed immediately), and which require a
+MMIO request to the emulation program. The access map can also inform
+the KVM drive which size accesses are allowed to the image.
+
+master descriptor
+^^^^^^^^^^^^^^^^^
+
+The master descriptor is used by QEMU to configure the new KVM device.
+The descriptor would be returned by the KVM driver when QEMU issues a
+*KVM\_CREATE\_DEVICE* ``ioctl()`` with a *KVM\_DEV\_TYPE\_USER* type.
+
+KVM\_DEV\_TYPE\_USER device ops
+
+
+The *KVM\_DEV\_TYPE\_USER* operations vector will be registered by a
+``kvm_register_device_ops()`` call when the KVM system in initialized by
+``kvm_init()``. These device ops are called by the KVM driver when QEMU
+executes certain ``ioctl()`` operations on its KVM file descriptor. They
+include:
+
+- create
+
+This routine is called when QEMU issues a *KVM\_CREATE\_DEVICE*
+``ioctl()`` on its per-VM file descriptor. It will allocate and
+initialize a KVM user device specific data structure, and assign the
+*kvm\_device* private field to it.
+
+- ioctl
+
+This routine is invoked when QEMU issues an ``ioctl()`` on the master
+descriptor. The ``ioctl()`` commands supported are defined by the KVM
+device type. *KVM\_DEV\_TYPE\_USER* ones will need several commands:
+
+*KVM\_DEV\_USER\_SLAVE\_FD* creates the slave file descriptor that will
+be passed to the device emulation program. Only one slave can be created
+by each master descriptor. The file operations performed by this
+descriptor are described below.
+
+The *KVM\_DEV\_USER\_PA\_RANGE* command configures a guest physical
+address range that the slave descriptor will receive MMIO notifications
+for. The range is specified by a guest physical range structure
+argument. For buses that assign addresses to devices dynamically, this
+command can be executed while the guest is running, such as the case
+when a guest changes a device's PCI BAR registers.
+
+*KVM\_DEV\_USER\_PA\_RANGE* will use ``kvm_io_bus_register_dev()`` to
+register *kvm\_io\_device\_ops* callbacks to be invoked when the guest
+performs a MMIO operation within the range. When a range is changed,
+``kvm_io_bus_unregister_dev()`` is used to remove the previous
+instantiation.
+
+*KVM\_DEV\_USER\_TIMEOUT* will configure a timeout value that specifies
+how long KVM will wait for the emulation process to respond to a MMIO
+indication.
+
+- destroy
+
+This routine is called when the VM instance is destroyed. It will need
+to destroy the slave descriptor; and free any memory allocated by the
+driver, as well as the *kvm\_device* structure itself.
+
+slave descriptor
+^^^^^^^^^^^^^^^^
+
+The slave descriptor will have its own file operations vector, which
+responds to system calls on the descriptor performed by the device
+emulation program.
+
+- read
+
+A read returns any pending MMIO requests from the KVM driver as MMIO
+request structures. Multiple structures can be returned if there are
+multiple MMIO operations pending. The MMIO requests are moved from the
+pending queue to the sent queue, and if there are threads waiting for
+space in the pending to add new MMIO operations, they will be woken
+here.
+
+- write
+
+A write also consists of a set of MMIO requests. They are compared to
+the MMIO requests in the sent queue. Matches are removed from the sent
+queue, and any threads waiting for the reply are woken. If a store is
+removed, then the number of posted stores in the per-CPU scoreboard is
+decremented. When the number is zero, and a non side-effect load was
+waiting for posted stores to complete, the load is continued.
+
+- ioctl
+
+There are several ioctl()s that can be performed on the slave
+descriptor.
+
+A *KVM\_DEV\_USER\_SHADOW\_SIZE* ``ioctl()`` causes the KVM driver to
+allocate memory for the shadow image. This memory can later be
+``mmap()``\ ed by the emulation process to share the emulation's view of
+device memory with the KVM driver.
+
+A *KVM\_DEV\_USER\_SHADOW\_CTRL* ``ioctl()`` controls access to the
+shadow image. It will send the KVM driver a shadow control map, which
+specifies which areas of the image can complete guest loads without
+sending the load request to the emulation program. It will also specify
+the size of load operations that are allowed.
+
+- poll
+
+An emulation program will use the ``poll()`` call with a *POLLIN* flag
+to determine if there are MMIO requests waiting to be read. It will
+return if the pending MMIO request queue is not empty.
+
+- mmap
+
+This call allows the emulation program to directly access the shadow
+image allocated by the KVM driver. As device emulation updates device
+memory, changes with no side-effects will be reflected in the shadow,
+and the KVM driver can satisfy guest loads from the shadow image without
+needing to wait for the emulation program.
+
+kvm\_io\_device ops
+^^^^^^^^^^^^^^^^^^^
+
+Each KVM per-CPU thread can handle MMIO operation on behalf of the guest
+VM. KVM will use the MMIO's guest physical address to search for a
+matching *kvm\_io\_device* to see if the MMIO can be handled by the KVM
+driver instead of exiting back to QEMU. If a match is found, the
+corresponding callback will be invoked.
+
+- read
+
+This callback is invoked when the guest performs a load to the device.
+Loads with side-effects must be handled synchronously, with the KVM
+driver putting the QEMU thread to sleep waiting for the emulation
+process reply before re-starting the guest. Loads that do not have
+side-effects may be optimized by satisfying them from the shadow image,
+if there are no outstanding stores to the device by this CPU. PCI memory
+ordering demands that a load cannot complete before all older stores to
+the same device have been completed.
+
+- write
+
+Stores can be handled asynchronously unless the pending MMIO request
+queue is full. In this case, the QEMU thread must sleep waiting for
+space in the queue. Stores will increment the number of posted stores in
+the per-CPU scoreboard, in order to implement the PCI ordering
+constraint above.
+
+interrupt acceleration
+^^^^^^^^^^^^^^^^^^^^^^
+
+This performance optimization would work much like a vhost user
+application does, where the QEMU process sets up *eventfds* that cause
+the device's corresponding interrupt to be triggered by the KVM driver.
+These irq file descriptors are sent to the emulation process at
+initialization, and are used when the emulation code raises a device
+interrupt.
+
+intx acceleration
+'''''''''''''''''
+
+Traditional PCI pin interrupts are level based, so, in addition to an
+irq file descriptor, a re-sampling file descriptor needs to be sent to
+the emulation program. This second file descriptor allows multiple
+devices sharing an irq to be notified when the interrupt has been
+acknowledged by the guest, so they can re-trigger the interrupt if their
+device has not de-asserted its interrupt.
+
+intx irq descriptor
+
+
+The irq descriptors are created by the proxy object
+``using event_notifier_init()`` to create the irq and re-sampling
+*eventds*, and ``kvm_vm_ioctl(KVM_IRQFD)`` to bind them to an interrupt.
+The interrupt route can be found with
+``pci_device_route_intx_to_irq()``.
+
+intx routing changes
+
+
+Intx routing can be changed when the guest programs the APIC the device
+pin is connected to. The proxy object in QEMU will use
+``pci_device_set_intx_routing_notifier()`` to be informed of any guest
+changes to the route. This handler will broadly follow the VFIO
+interrupt logic to change the route: de-assigning the existing irq
+descriptor from its route, then assigning it the new route. (see
+``vfio_intx_update()``)
+
+MSI/X acceleration
+''''''''''''''''''
+
+MSI/X interrupts are sent as DMA transactions to the host. The interrupt
+data contains a vector that is programmed by the guest, A device may have
+multiple MSI interrupts associated with it, so multiple irq descriptors
+may need to be sent to the emulation program.
+
+MSI/X irq descriptor
+
+
+This case will also follow the VFIO example. For each MSI/X interrupt,
+an *eventfd* is created, a virtual interrupt is allocated by
+``kvm_irqchip_add_msi_route()``, and the virtual interrupt is bound to
+the eventfd with ``kvm_irqchip_add_irqfd_notifier()``.
+
+MSI/X config space changes
+
+
+The guest may dynamically update several MSI-related tables in the
+device's PCI config space. These include per-MSI interrupt enables and
+vector data. Additionally, MSIX tables exist in device memory space, not
+config space. Much like the BAR case above, the proxy object must look
+at guest config space programming to keep the MSI interrupt state
+consistent between QEMU and the emulation program.
+
+--------------
+
+Disaggregated CPU emulation
+---------------------------
+
+After IO services have been disaggregated, a second phase would be to
+separate a process to handle CPU instruction emulation from the main
+QEMU control function. There are no object separation points for this
+code, so the first task would be to create one.
+
+Host access controls
+--------------------
+
+Separating QEMU relies on the host OS's access restriction mechanisms to
+enforce that the differing processes can only access the objects they
+are entitled to. There are a couple types of mechanisms usually provided
+by general purpose OSs.
+
+Discretionary access control
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Discretionary access control allows each user to control who can access
+their files. In Linux, this type of control is usually too coarse for
+QEMU separation, since it only provides three separate access controls:
+one for the same user ID, the second for users IDs with the same group
+ID, and the third for all other user IDs. Each device instance would
+need a separate user ID to provide access control, which is likely to be
+unwieldy for dynamically created VMs.
+
+Mandatory access control
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Mandatory access control allows the OS to add an additional set of
+controls on top of discretionary access for the OS to control. It also
+adds other attributes to processes and files such as types, roles, and
+categories, and can establish rules for how processes and files can
+interact.
+
+Type enforcement
+^^^^^^^^^^^^^^^^
+
+Type enforcement assigns a *type* attribute to processes and files, and
+allows rules to be written on what operations a process with a given
+type can perform on a file with a given type. QEMU separation could take
+advantage of type enforcement by running the emulation processes with
+different types, both from the main QEMU process, and from the emulation
+processes of different classes of devices.
+
+For example, guest disk images and disk emulation processes could have
+types separate from the main QEMU process and non-disk emulation
+processes, and the type rules could prevent processes other than disk
+emulation ones from accessing guest disk images. Similarly, network
+emulation processes can have a type separate from the main QEMU process
+and non-network emulation process, and only that type can access the
+host tun/tap device used to provide guest networking.
+
+Category enforcement
+^^^^^^^^^^^^^^^^^^^^
+
+Category enforcement assigns a set of numbers within a given range to
+the process or file. The process is granted access to the file if the
+process's set is a superset of the file's set. This enforcement can be
+used to separate multiple instances of devices in the same class.
+
+For example, if there are multiple disk devices provides to a guest,
+each device emulation process could be provisioned with a separate
+category. The different device emulation processes would not be able to
+access each other's backing disk images.
+
+Alternatively, categories could be used in lieu of the type enforcement
+scheme described above. In this scenario, different categories would be
+used to prevent device emulation processes in different classes from
+accessing resources assigned to other classes.
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH RESEND v6 36/36] multi-process: add configure and usage information
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (34 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 35/36] multi-process: add the concept description to docs/devel/qemu-multiprocess elena.ufimtseva
@ 2020-04-23 4:14 ` elena.ufimtseva
2020-04-23 13:54 ` 罗勇刚(Yonggang Luo)
2020-04-24 12:48 ` [PATCH RESEND v6 00/36] Initial support for multi-process qemu Stefan Hajnoczi
` (2 subsequent siblings)
38 siblings, 1 reply; 94+ messages in thread
From: elena.ufimtseva @ 2020-04-23 4:14 UTC (permalink / raw)
To: qemu-devel
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, kraxel,
jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
---
MAINTAINERS | 2 +
docs/multi-process.rst | 85 +++++++++++++++++++++++++
scripts/mpqemu-launcher-perf-mode.py | 92 ++++++++++++++++++++++++++++
scripts/mpqemu-launcher.py | 53 ++++++++++++++++
4 files changed, 232 insertions(+)
create mode 100644 docs/multi-process.rst
create mode 100755 scripts/mpqemu-launcher-perf-mode.py
create mode 100755 scripts/mpqemu-launcher.py
diff --git a/MAINTAINERS b/MAINTAINERS
index ed48615e15..8ff3bfae6a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2880,6 +2880,8 @@ F: remote/iohub.c
F: remote/remote-opts.h
F: remote/remote-opts.c
F: docs/devel/multi-process.rst
+F: scripts/mpqemu-launcher.py
+F: scripts/mpqemu-launcher-perf-mode.py
Build and test automation
-------------------------
diff --git a/docs/multi-process.rst b/docs/multi-process.rst
new file mode 100644
index 0000000000..8387d6c691
--- /dev/null
+++ b/docs/multi-process.rst
@@ -0,0 +1,85 @@
+Multi-process QEMU
+==================
+
+This document describes how to configure and use multi-process qemu.
+For the design document refer to docs/devel/qemu-multiprocess.
+
+1) Configuration
+----------------
+
+To enable support for multi-process add --enable-mpqemu
+to the list of options for the "configure" script.
+
+
+2) Usage
+--------
+
+Multi-process QEMU requires an orchestrator to launch. Please refer to a
+light-weight python based orchestrator for mpqemu in
+scripts/mpqemu-launcher.py to lauch QEMU in multi-process mode.
+
+scripts/mpqemu-launcher-perf-mode.py launches in "perf" mode. In this mode,
+the same QEMU process connects to multiple remote devices, each emulated in
+a separate process.
+
+As of now, we only support the emulation of lsi53c895a in a separate process.
+
+Following is a description of command-line used to launch mpqemu.
+
+* Orchestrator:
+
+ - The Orchestrator creates a unix socketpair
+
+ - It launches the remote process and passes one of the
+ sockets to it via command-line.
+
+ - It then launches QEMU and specifies the other socket as an option
+ to the Proxy device object
+
+* Remote Process:
+
+ - The first command-line option in the remote process is one of the
+ sockets created by the Orchestrator
+
+ - The remaining options are no different from how one launches QEMU with
+ devices. The only other requirement is each PCI device must have a
+ unique ID specified to it. This is needed to pair remote device with the
+ Proxy object.
+
+ - Example command-line for the remote process is as follows:
+
+ /usr/bin/qemu-scsu-dev 4 \
+ -device lsi53c895a,id=lsi0 \
+ -drive id=drive_image2,file=/build/ol7-nvme-test-1.qcow2 \
+ -device scsi-hd,id=drive2,drive=drive_image2,bus=lsi0.0,scsi-id=0
+
+* QEMU:
+
+ - Since parts of the RAM are shared between QEMU & remote process, a
+ memory-backend-memfd is required to facilitate this, as follows:
+
+ -object memory-backend-memfd,id=mem,size=2G
+
+ - A "pci-proxy-dev" device is created for each of the PCI devices emulated
+ in the remote process. A "socket" sub-option specifies the other end of
+ unix channel created by orchestrator. The "id" sub-option must be specified
+ and should be the same as the "id" specified for the remote PCI device
+
+ - Example commandline for QEMU is as follows:
+
+ -device pci-proxy-dev,id=lsi0,socket=3
+
+* Monitor / QMP:
+
+ - The remote process supports QEMU monitor. It could be specified using the
+ "-monitor" or "-qmp" command-line options
+
+ - As an example, one could connect to the monitor by adding the following
+ to the command-line of the remote process
+
+ -monitor unix:/home/qmp-sock,server,nowait
+
+ - The user could connect to the monitor using the qmp script or using
+ "socat" as outlined below:
+
+ socat /home/qmp-sock stdio
diff --git a/scripts/mpqemu-launcher-perf-mode.py b/scripts/mpqemu-launcher-perf-mode.py
new file mode 100755
index 0000000000..2733424c76
--- /dev/null
+++ b/scripts/mpqemu-launcher-perf-mode.py
@@ -0,0 +1,92 @@
+#!/usr/bin/env python3
+
+import socket
+import os
+import subprocess
+import time
+
+PROC_QEMU='/usr/bin/qemu-system-x86_64'
+
+PROC_REMOTE='/usr/bin/qemu-scsi-dev'
+
+proxy_1, remote_1 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
+proxy_2, remote_2 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
+proxy_3, remote_3 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
+
+remote_cmd_1 = [ PROC_REMOTE, \
+ str(remote_1.fileno()), \
+ '-device', 'lsi53c895a,id=lsi1', \
+ '-drive', 'id=drive_image1,' \
+ 'file=/build/ol7-nvme-test-1.qcow2', \
+ '-device', 'scsi-hd,id=drive1,drive=drive_image1,' \
+ 'bus=lsi1.0,scsi-id=0', \
+ ]
+
+remote_cmd_2 = [ PROC_REMOTE, \
+ str(remote_2.fileno()), \
+ '-device', 'lsi53c895a,id=lsi2', \
+ '-drive', 'id=drive_image2,' \
+ 'file=/build/ol7-nvme-test-2.qcow2', \
+ '-device', 'scsi-hd,id=drive2,drive=drive_image2,' \
+ 'bus=lsi2.0,scsi-id=0' \
+ ]
+
+remote_cmd_3 = [ PROC_REMOTE, \
+ str(remote_3.fileno()), \
+ '-device', 'lsi53c895a,id=lsi3', \
+ '-drive', 'id=drive_image3,' \
+ 'file=/build/ol7-nvme-test-3.qcow2', \
+ '-device', 'scsi-hd,id=drive3,drive=drive_image3,' \
+ 'bus=lsi3.0,scsi-id=0' \
+ ]
+
+proxy_cmd = [ PROC_QEMU, \
+ '-name', 'OL7.4', \
+ '-machine', 'q35,accel=kvm', \
+ '-smp', 'sockets=1,cores=1,threads=1', \
+ '-m', '2048', \
+ '-object', 'memory-backend-memfd,id=sysmem-file,size=2G', \
+ '-numa', 'node,memdev=sysmem-file', \
+ '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0', \
+ '-drive', 'id=drive_image1,if=none,format=qcow2,' \
+ 'file=/home/ol7-hdd-1.qcow2', \
+ '-device', 'scsi-hd,id=image1,drive=drive_image1,' \
+ 'bus=virtio_scsi_pci0.0', \
+ '-boot', 'd', \
+ '-vnc', ':0', \
+ '-device', 'pci-proxy-dev,id=lsi1,' \
+ 'socket='+str(proxy_1.fileno()), \
+ '-device', 'pci-proxy-dev,id=lsi2,' \
+ 'socket='+str(proxy_2.fileno()), \
+ '-device', 'pci-proxy-dev,id=lsi3,' \
+ 'socket='+str(proxy_3.fileno()) \
+ ]
+
+
+pid = os.fork();
+if pid == 0:
+ # In remote_1
+ print('Launching Remote process 1');
+ process = subprocess.Popen(remote_cmd_1, pass_fds=[remote_1.fileno()])
+ os._exit(0)
+
+
+pid = os.fork();
+if pid == 0:
+ # In remote_2
+ print('Launching Remote process 2');
+ process = subprocess.Popen(remote_cmd_2, pass_fds=[remote_2.fileno()])
+ os._exit(0)
+
+
+pid = os.fork();
+if pid == 0:
+ # In remote_3
+ print('Launching Remote process 3');
+ process = subprocess.Popen(remote_cmd_3, pass_fds=[remote_3.fileno()])
+ os._exit(0)
+
+
+print('Launching Proxy process');
+process = subprocess.Popen(proxy_cmd, pass_fds=[proxy_1.fileno(), \
+ proxy_2.fileno(), proxy_3.fileno()])
diff --git a/scripts/mpqemu-launcher.py b/scripts/mpqemu-launcher.py
new file mode 100755
index 0000000000..81e370663e
--- /dev/null
+++ b/scripts/mpqemu-launcher.py
@@ -0,0 +1,53 @@
+#!/usr/bin/env python3
+import socket
+import os
+import subprocess
+import time
+
+PROC_QEMU='/usr/bin/qemu-system-x86_64'
+
+PROC_REMOTE='/usr/bin/qemu-scsi-dev'
+
+proxy, remote = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
+
+remote_cmd = [ PROC_REMOTE, \
+ str(remote.fileno()), \
+ '-device', 'lsi53c895a,id=lsi1', \
+ '-drive', 'id=drive_image1,file=/build/ol7-nvme-test-1.qcow2', \
+ '-device', 'scsi-hd,id=drive1,drive=drive_image1,bus=lsi1.0,' \
+ 'scsi-id=0', \
+ '-device', 'lsi53c895a,id=lsi2', \
+ '-drive', 'id=drive_image2,file=/build/ol7-nvme-test-2.qcow2', \
+ '-device', 'scsi-hd,id=drive2,drive=drive_image2,bus=lsi2.0,' \
+ 'scsi-id=0' \
+ ]
+
+proxy_cmd = [ PROC_QEMU, \
+ '-name', 'OL7.4', \
+ '-machine', 'q35,accel=kvm', \
+ '-smp', 'sockets=1,cores=1,threads=1', \
+ '-m', '2048', \
+ '-object', 'memory-backend-memfd,id=sysmem-file,size=2G', \
+ '-numa', 'node,memdev=sysmem-file', \
+ '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0', \
+ '-drive', 'id=drive_image1,if=none,format=qcow2,' \
+ 'file=/home/ol7-hdd-1.qcow2', \
+ '-device', 'scsi-hd,id=image1,drive=drive_image1,' \
+ 'bus=virtio_scsi_pci0.0', \
+ '-boot', 'd', \
+ '-vnc', ':0', \
+ '-device', 'pci-proxy-dev,id=lsi1,socket='+str(proxy.fileno()), \
+ '-device', 'pci-proxy-dev,id=lsi2,socket='+str(proxy.fileno()) \
+ ]
+
+
+pid = os.fork();
+
+if pid:
+ # In Proxy
+ print('Launching QEMU with Proxy object');
+ process = subprocess.Popen(proxy_cmd, pass_fds=[proxy.fileno()])
+else:
+ # In remote
+ print('Launching Remote process');
+ process = subprocess.Popen(remote_cmd, pass_fds=[remote.fileno()])
--
2.25.GIT
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 36/36] multi-process: add configure and usage information
2020-04-23 4:14 ` [PATCH RESEND v6 36/36] multi-process: add configure and usage information elena.ufimtseva
@ 2020-04-23 13:54 ` 罗勇刚(Yonggang Luo)
2020-04-23 15:01 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: 罗勇刚(Yonggang Luo) @ 2020-04-23 13:54 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha, pbonzini,
rth, kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 11824 bytes --]
Does multi-process support on Windows?
I found it use mmap and unix socket for inter-process communication, that
may not support under Windows.
And also, can the python script be replaced by C implementation?
On Thu, Apr 23, 2020 at 12:38 PM <elena.ufimtseva@oracle.com> wrote:
> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> ---
> MAINTAINERS | 2 +
> docs/multi-process.rst | 85 +++++++++++++++++++++++++
> scripts/mpqemu-launcher-perf-mode.py | 92 ++++++++++++++++++++++++++++
> scripts/mpqemu-launcher.py | 53 ++++++++++++++++
> 4 files changed, 232 insertions(+)
> create mode 100644 docs/multi-process.rst
> create mode 100755 scripts/mpqemu-launcher-perf-mode.py
> create mode 100755 scripts/mpqemu-launcher.py
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ed48615e15..8ff3bfae6a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2880,6 +2880,8 @@ F: remote/iohub.c
> F: remote/remote-opts.h
> F: remote/remote-opts.c
> F: docs/devel/multi-process.rst
> +F: scripts/mpqemu-launcher.py
> +F: scripts/mpqemu-launcher-perf-mode.py
>
> Build and test automation
> -------------------------
> diff --git a/docs/multi-process.rst b/docs/multi-process.rst
> new file mode 100644
> index 0000000000..8387d6c691
> --- /dev/null
> +++ b/docs/multi-process.rst
> @@ -0,0 +1,85 @@
> +Multi-process QEMU
> +==================
> +
> +This document describes how to configure and use multi-process qemu.
> +For the design document refer to docs/devel/qemu-multiprocess.
> +
> +1) Configuration
> +----------------
> +
> +To enable support for multi-process add --enable-mpqemu
> +to the list of options for the "configure" script.
> +
> +
> +2) Usage
> +--------
> +
> +Multi-process QEMU requires an orchestrator to launch. Please refer to a
> +light-weight python based orchestrator for mpqemu in
> +scripts/mpqemu-launcher.py to lauch QEMU in multi-process mode.
> +
> +scripts/mpqemu-launcher-perf-mode.py launches in "perf" mode. In this
> mode,
> +the same QEMU process connects to multiple remote devices, each emulated
> in
> +a separate process.
> +
> +As of now, we only support the emulation of lsi53c895a in a separate
> process.
> +
> +Following is a description of command-line used to launch mpqemu.
> +
> +* Orchestrator:
> +
> + - The Orchestrator creates a unix socketpair
> +
> + - It launches the remote process and passes one of the
> + sockets to it via command-line.
> +
> + - It then launches QEMU and specifies the other socket as an option
> + to the Proxy device object
> +
> +* Remote Process:
> +
> + - The first command-line option in the remote process is one of the
> + sockets created by the Orchestrator
> +
> + - The remaining options are no different from how one launches QEMU with
> + devices. The only other requirement is each PCI device must have a
> + unique ID specified to it. This is needed to pair remote device with
> the
> + Proxy object.
> +
> + - Example command-line for the remote process is as follows:
> +
> + /usr/bin/qemu-scsu-dev 4 \
> + -device lsi53c895a,id=lsi0 \
> + -drive id=drive_image2,file=/build/ol7-nvme-test-1.qcow2 \
> + -device scsi-hd,id=drive2,drive=drive_image2,bus=lsi0.0,scsi-id=0
> +
> +* QEMU:
> +
> + - Since parts of the RAM are shared between QEMU & remote process, a
> + memory-backend-memfd is required to facilitate this, as follows:
> +
> + -object memory-backend-memfd,id=mem,size=2G
> +
> + - A "pci-proxy-dev" device is created for each of the PCI devices
> emulated
> + in the remote process. A "socket" sub-option specifies the other end
> of
> + unix channel created by orchestrator. The "id" sub-option must be
> specified
> + and should be the same as the "id" specified for the remote PCI device
> +
> + - Example commandline for QEMU is as follows:
> +
> + -device pci-proxy-dev,id=lsi0,socket=3
> +
> +* Monitor / QMP:
> +
> + - The remote process supports QEMU monitor. It could be specified using
> the
> + "-monitor" or "-qmp" command-line options
> +
> + - As an example, one could connect to the monitor by adding the
> following
> + to the command-line of the remote process
> +
> + -monitor unix:/home/qmp-sock,server,nowait
> +
> + - The user could connect to the monitor using the qmp script or using
> + "socat" as outlined below:
> +
> + socat /home/qmp-sock stdio
> diff --git a/scripts/mpqemu-launcher-perf-mode.py
> b/scripts/mpqemu-launcher-perf-mode.py
> new file mode 100755
> index 0000000000..2733424c76
> --- /dev/null
> +++ b/scripts/mpqemu-launcher-perf-mode.py
> @@ -0,0 +1,92 @@
> +#!/usr/bin/env python3
> +
> +import socket
> +import os
> +import subprocess
> +import time
> +
> +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> +
> +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> +
> +proxy_1, remote_1 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +proxy_2, remote_2 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +proxy_3, remote_3 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +
> +remote_cmd_1 = [ PROC_REMOTE,
> \
> + str(remote_1.fileno()),
> \
> + '-device', 'lsi53c895a,id=lsi1',
> \
> + '-drive', 'id=drive_image1,'
> \
> + 'file=/build/ol7-nvme-test-1.qcow2',
> \
> + '-device', 'scsi-hd,id=drive1,drive=drive_image1,'
> \
> + 'bus=lsi1.0,scsi-id=0',
> \
> + ]
> +
> +remote_cmd_2 = [ PROC_REMOTE,
> \
> + str(remote_2.fileno()),
> \
> + '-device', 'lsi53c895a,id=lsi2',
> \
> + '-drive', 'id=drive_image2,'
> \
> + 'file=/build/ol7-nvme-test-2.qcow2',
> \
> + '-device', 'scsi-hd,id=drive2,drive=drive_image2,'
> \
> + 'bus=lsi2.0,scsi-id=0'
> \
> + ]
> +
> +remote_cmd_3 = [ PROC_REMOTE,
> \
> + str(remote_3.fileno()),
> \
> + '-device', 'lsi53c895a,id=lsi3',
> \
> + '-drive', 'id=drive_image3,'
> \
> + 'file=/build/ol7-nvme-test-3.qcow2',
> \
> + '-device', 'scsi-hd,id=drive3,drive=drive_image3,'
> \
> + 'bus=lsi3.0,scsi-id=0'
> \
> + ]
> +
> +proxy_cmd = [ PROC_QEMU,
> \
> + '-name', 'OL7.4',
> \
> + '-machine', 'q35,accel=kvm',
> \
> + '-smp', 'sockets=1,cores=1,threads=1',
> \
> + '-m', '2048',
> \
> + '-object', 'memory-backend-memfd,id=sysmem-file,size=2G',
> \
> + '-numa', 'node,memdev=sysmem-file',
> \
> + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0',
> \
> + '-drive', 'id=drive_image1,if=none,format=qcow2,'
> \
> + 'file=/home/ol7-hdd-1.qcow2',
> \
> + '-device', 'scsi-hd,id=image1,drive=drive_image1,'
> \
> + 'bus=virtio_scsi_pci0.0',
> \
> + '-boot', 'd',
> \
> + '-vnc', ':0',
> \
> + '-device', 'pci-proxy-dev,id=lsi1,'
> \
> + 'socket='+str(proxy_1.fileno()),
> \
> + '-device', 'pci-proxy-dev,id=lsi2,'
> \
> + 'socket='+str(proxy_2.fileno()),
> \
> + '-device', 'pci-proxy-dev,id=lsi3,'
> \
> + 'socket='+str(proxy_3.fileno())
> \
> + ]
> +
> +
> +pid = os.fork();
> +if pid == 0:
> + # In remote_1
> + print('Launching Remote process 1');
> + process = subprocess.Popen(remote_cmd_1, pass_fds=[remote_1.fileno()])
> + os._exit(0)
> +
> +
> +pid = os.fork();
> +if pid == 0:
> + # In remote_2
> + print('Launching Remote process 2');
> + process = subprocess.Popen(remote_cmd_2, pass_fds=[remote_2.fileno()])
> + os._exit(0)
> +
> +
> +pid = os.fork();
> +if pid == 0:
> + # In remote_3
> + print('Launching Remote process 3');
> + process = subprocess.Popen(remote_cmd_3, pass_fds=[remote_3.fileno()])
> + os._exit(0)
> +
> +
> +print('Launching Proxy process');
> +process = subprocess.Popen(proxy_cmd, pass_fds=[proxy_1.fileno(),
> \
> + proxy_2.fileno(), proxy_3.fileno()])
> diff --git a/scripts/mpqemu-launcher.py b/scripts/mpqemu-launcher.py
> new file mode 100755
> index 0000000000..81e370663e
> --- /dev/null
> +++ b/scripts/mpqemu-launcher.py
> @@ -0,0 +1,53 @@
> +#!/usr/bin/env python3
> +import socket
> +import os
> +import subprocess
> +import time
> +
> +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> +
> +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> +
> +proxy, remote = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +
> +remote_cmd = [ PROC_REMOTE,
> \
> + str(remote.fileno()),
> \
> + '-device', 'lsi53c895a,id=lsi1',
> \
> + '-drive',
> 'id=drive_image1,file=/build/ol7-nvme-test-1.qcow2', \
> + '-device',
> 'scsi-hd,id=drive1,drive=drive_image1,bus=lsi1.0,' \
> + 'scsi-id=0',
> \
> + '-device', 'lsi53c895a,id=lsi2',
> \
> + '-drive',
> 'id=drive_image2,file=/build/ol7-nvme-test-2.qcow2', \
> + '-device',
> 'scsi-hd,id=drive2,drive=drive_image2,bus=lsi2.0,' \
> + 'scsi-id=0'
> \
> + ]
> +
> +proxy_cmd = [ PROC_QEMU,
> \
> + '-name', 'OL7.4',
> \
> + '-machine', 'q35,accel=kvm',
> \
> + '-smp', 'sockets=1,cores=1,threads=1',
> \
> + '-m', '2048',
> \
> + '-object', 'memory-backend-memfd,id=sysmem-file,size=2G',
> \
> + '-numa', 'node,memdev=sysmem-file',
> \
> + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0',
> \
> + '-drive', 'id=drive_image1,if=none,format=qcow2,'
> \
> + 'file=/home/ol7-hdd-1.qcow2',
> \
> + '-device', 'scsi-hd,id=image1,drive=drive_image1,'
> \
> + 'bus=virtio_scsi_pci0.0',
> \
> + '-boot', 'd',
> \
> + '-vnc', ':0',
> \
> + '-device',
> 'pci-proxy-dev,id=lsi1,socket='+str(proxy.fileno()), \
> + '-device',
> 'pci-proxy-dev,id=lsi2,socket='+str(proxy.fileno()) \
> + ]
> +
> +
> +pid = os.fork();
> +
> +if pid:
> + # In Proxy
> + print('Launching QEMU with Proxy object');
> + process = subprocess.Popen(proxy_cmd, pass_fds=[proxy.fileno()])
> +else:
> + # In remote
> + print('Launching Remote process');
> + process = subprocess.Popen(remote_cmd, pass_fds=[remote.fileno()])
> --
> 2.25.GIT
>
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
[-- Attachment #2: Type: text/html, Size: 17077 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 02/36] multi-process: Refactor machine_init and exit notifiers
2020-04-23 4:13 ` [PATCH RESEND v6 02/36] multi-process: Refactor machine_init and exit notifiers elena.ufimtseva
@ 2020-04-23 14:13 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 94+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-23 14:13 UTC (permalink / raw)
To: elena.ufimtseva, qemu-devel, marcandre.lureau, pbonzini
Cc: fam, john.g.johnson, swapnil.ingle, mst, kraxel, jag.raman,
quintela, armbru, kanth.ghatraju, felipe, thuth, ehabkost,
konrad.wilk, dgilbert, liran.alon, stefanha, rth, kwolf,
berrange, mreitz, ross.lagerwall, thanos.makatos
On 4/23/20 6:13 AM, elena.ufimtseva@oracle.com wrote:
> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>
> Relocate machine_int and exit notifiers into common code
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> ---
> MAINTAINERS | 1 +
> Makefile.objs | 1 +
> include/sysemu/sysemu.h | 2 ++
> softmmu/vl.c | 42 ----------------------
> stubs/Makefile.objs | 2 ++
> stubs/machine-init-add.c | 7 ++++
> stubs/machine-init-done.c | 5 ++-
> stubs/machine-init-remove.c | 8 +++++
> util/machine-notify.c | 69 +++++++++++++++++++++++++++++++++++++
> 9 files changed, 92 insertions(+), 45 deletions(-)
> create mode 100644 stubs/machine-init-add.c
> create mode 100644 stubs/machine-init-remove.c
> create mode 100644 util/machine-notify.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8cbc1fac2b..04b19ac56c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2133,6 +2133,7 @@ F: util/qemu-timer.c
> F: softmmu/vl.c
> F: softmmu/main.c
> F: qapi/run-state.json
> +F: util/machine-notify.c
>
> Human Monitor (HMP)
> M: Dr. David Alan Gilbert <dgilbert@redhat.com>
> diff --git a/Makefile.objs b/Makefile.objs
> index a7c967633a..bfb9271862 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -79,6 +79,7 @@ qemu-seccomp.o-libs := $(SECCOMP_LIBS)
> common-obj-$(CONFIG_FDT) += device_tree.o
>
> common-obj-y += qapi/
> +common-obj-y += util/machine-notify.o
>
> endif # CONFIG_SOFTMMU
>
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index ef81302e1a..2438dd7bea 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -17,11 +17,13 @@ extern bool qemu_uuid_set;
>
> void qemu_add_exit_notifier(Notifier *notify);
> void qemu_remove_exit_notifier(Notifier *notify);
> +void qemu_run_exit_notifiers(void);
>
> extern bool machine_init_done;
>
> void qemu_add_machine_init_done_notifier(Notifier *notify);
> void qemu_remove_machine_init_done_notifier(Notifier *notify);
> +void qemu_run_machine_init_done_notifiers(void);
>
> extern int autostart;
>
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index 32c0047889..39cbb6b50d 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -172,12 +172,6 @@ int icount_align_option;
> QemuUUID qemu_uuid;
> bool qemu_uuid_set;
>
> -static NotifierList exit_notifiers =
> - NOTIFIER_LIST_INITIALIZER(exit_notifiers);
> -
> -static NotifierList machine_init_done_notifiers =
> - NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
> -
> bool xen_allowed;
> uint32_t xen_domid;
> enum xen_mode xen_mode = XEN_EMULATE;
> @@ -2325,21 +2319,6 @@ static MachineClass *machine_parse(const char *name, GSList *machines)
> return mc;
> }
>
> -void qemu_add_exit_notifier(Notifier *notify)
> -{
> - notifier_list_add(&exit_notifiers, notify);
> -}
> -
> -void qemu_remove_exit_notifier(Notifier *notify)
> -{
> - notifier_remove(notify);
> -}
> -
> -static void qemu_run_exit_notifiers(void)
> -{
> - notifier_list_notify(&exit_notifiers, NULL);
> -}
> -
> static const char *pid_file;
> static Notifier qemu_unlink_pidfile_notifier;
>
> @@ -2350,27 +2329,6 @@ static void qemu_unlink_pidfile(Notifier *n, void *data)
> }
> }
>
> -bool machine_init_done;
> -
> -void qemu_add_machine_init_done_notifier(Notifier *notify)
> -{
> - notifier_list_add(&machine_init_done_notifiers, notify);
> - if (machine_init_done) {
> - notify->notify(notify, NULL);
> - }
> -}
> -
> -void qemu_remove_machine_init_done_notifier(Notifier *notify)
> -{
> - notifier_remove(notify);
> -}
> -
> -static void qemu_run_machine_init_done_notifiers(void)
> -{
> - machine_init_done = true;
> - notifier_list_notify(&machine_init_done_notifiers, NULL);
> -}
> -
> static const QEMUOption *lookup_opt(int argc, char **argv,
> const char **poptarg, int *poptind)
> {
> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> index 45be5dc0ed..f884bb6180 100644
> --- a/stubs/Makefile.objs
> +++ b/stubs/Makefile.objs
> @@ -43,4 +43,6 @@ stub-obj-y += pci-host-piix.o
> stub-obj-y += ram-block.o
> stub-obj-y += ramfb.o
> stub-obj-y += fw_cfg.o
> +stub-obj-y += machine-init-add.o
> +stub-obj-y += machine-init-remove.o
Trying to understand why we have this stub here...
So per commit 07a32d6b962 it is required by the chardev driver.
Marc-André, what do you think about extracting chardev_machine_*() to
chardev/char-sysemu.c and simply add to chardev/Makefile:
chardev-obj-$(CONFIG_SOFTMMU) += char-sysemu.o
> stub-obj-$(CONFIG_SOFTMMU) += semihost.o
> diff --git a/stubs/machine-init-add.c b/stubs/machine-init-add.c
> new file mode 100644
> index 0000000000..520dcb9801
> --- /dev/null
> +++ b/stubs/machine-init-add.c
> @@ -0,0 +1,7 @@
> +#include "qemu/osdep.h"
> +#include "sysemu/sysemu.h"
> +
> +void qemu_add_machine_init_done_notifier(Notifier *notify)
> +{
> +}
> +
> diff --git a/stubs/machine-init-done.c b/stubs/machine-init-done.c
> index cd8e81392d..a34d838f7a 100644
> --- a/stubs/machine-init-done.c
> +++ b/stubs/machine-init-done.c
> @@ -3,6 +3,5 @@
>
> bool machine_init_done = true;
>
> -void qemu_add_machine_init_done_notifier(Notifier *notify)
> -{
> -}
> +NotifierList machine_init_done_notifiers =
> + NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
> diff --git a/stubs/machine-init-remove.c b/stubs/machine-init-remove.c
> new file mode 100644
> index 0000000000..30aee27c2d
> --- /dev/null
> +++ b/stubs/machine-init-remove.c
> @@ -0,0 +1,8 @@
> +#include "qemu/osdep.h"
> +#include "sysemu/sysemu.h"
> +
> +void qemu_remove_machine_init_done_notifier(Notifier *notify)
> +{
> +}
> +
> +
> diff --git a/util/machine-notify.c b/util/machine-notify.c
> new file mode 100644
> index 0000000000..718af79335
> --- /dev/null
> +++ b/util/machine-notify.c
> @@ -0,0 +1,69 @@
> +/*
> + * Machine notifiers.
> + *
> + * Copyright (c) 2003-2008 Fabrice Bellard
> + *
> + * 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/notify.h"
> +#include "sysemu/sysemu.h"
> +
> +static NotifierList machine_init_done_notifiers =
> + NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
> +
> +static NotifierList exit_notifiers =
> + NOTIFIER_LIST_INITIALIZER(exit_notifiers);
> +
> +bool machine_init_done;
> +
> +void qemu_add_machine_init_done_notifier(Notifier *notify)
> +{
> + notifier_list_add(&machine_init_done_notifiers, notify);
> + if (machine_init_done) {
> + notify->notify(notify, NULL);
> + }
> +}
> +
> +void qemu_remove_machine_init_done_notifier(Notifier *notify)
> +{
> + notifier_remove(notify);
> +}
> +
> +void qemu_run_machine_init_done_notifiers(void)
> +{
> + machine_init_done = true;
> + notifier_list_notify(&machine_init_done_notifiers, NULL);
> +}
> +
> +void qemu_add_exit_notifier(Notifier *notify)
> +{
> + notifier_list_add(&exit_notifiers, notify);
> +}
> +
> +void qemu_remove_exit_notifier(Notifier *notify)
> +{
> + notifier_remove(notify);
> +}
> +
> +void qemu_run_exit_notifiers(void)
> +{
> + notifier_list_notify(&exit_notifiers, NULL);
> +}
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 06/36] monitor: destaticize HMP commands
2020-04-23 4:13 ` [PATCH RESEND v6 06/36] monitor: destaticize HMP commands elena.ufimtseva
@ 2020-04-23 14:14 ` Philippe Mathieu-Daudé
2020-04-23 15:07 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-23 14:14 UTC (permalink / raw)
To: elena.ufimtseva, qemu-devel
Cc: fam, john.g.johnson, swapnil.ingle, mst, kraxel, jag.raman,
quintela, armbru, kanth.ghatraju, felipe, thuth, ehabkost,
konrad.wilk, dgilbert, liran.alon, stefanha, pbonzini, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
Why 'destaticize HMP commands'?
On 4/23/20 6:13 AM, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
> hmp-commands.hx | 4 +-
> monitor/misc.c | 76 +++++++++++++++++++-------------------
> monitor/monitor-internal.h | 38 +++++++++++++++++++
> 3 files changed, 78 insertions(+), 40 deletions(-)
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 36/36] multi-process: add configure and usage information
2020-04-23 13:54 ` 罗勇刚(Yonggang Luo)
@ 2020-04-23 15:01 ` Jag Raman
2020-04-23 22:56 ` 罗勇刚(Yonggang Luo)
2020-04-24 0:34 ` 罗勇刚(Yonggang Luo)
0 siblings, 2 replies; 94+ messages in thread
From: Jag Raman @ 2020-04-23 15:01 UTC (permalink / raw)
To: luoyonggang
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha, pbonzini,
rth, kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
> On Apr 23, 2020, at 9:54 AM, 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com> wrote:
>
> Does multi-process support on Windows?
> I found it use mmap and unix socket for inter-process communication, that may not support under Windows.
Hi Yonggang,
We have only tested this on Linux till now. Are you using QEMU with Windows?
> And also, can the python script be replaced by C implementation?
The functionality in the python script would eventually move to libvirt. The python
script is a temporary measure.
Thank you very much!
—
Jag
>
> On Thu, Apr 23, 2020 at 12:38 PM <elena.ufimtseva@oracle.com> wrote:
> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> ---
> MAINTAINERS | 2 +
> docs/multi-process.rst | 85 +++++++++++++++++++++++++
> scripts/mpqemu-launcher-perf-mode.py | 92 ++++++++++++++++++++++++++++
> scripts/mpqemu-launcher.py | 53 ++++++++++++++++
> 4 files changed, 232 insertions(+)
> create mode 100644 docs/multi-process.rst
> create mode 100755 scripts/mpqemu-launcher-perf-mode.py
> create mode 100755 scripts/mpqemu-launcher.py
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ed48615e15..8ff3bfae6a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2880,6 +2880,8 @@ F: remote/iohub.c
> F: remote/remote-opts.h
> F: remote/remote-opts.c
> F: docs/devel/multi-process.rst
> +F: scripts/mpqemu-launcher.py
> +F: scripts/mpqemu-launcher-perf-mode.py
>
> Build and test automation
> -------------------------
> diff --git a/docs/multi-process.rst b/docs/multi-process.rst
> new file mode 100644
> index 0000000000..8387d6c691
> --- /dev/null
> +++ b/docs/multi-process.rst
> @@ -0,0 +1,85 @@
> +Multi-process QEMU
> +==================
> +
> +This document describes how to configure and use multi-process qemu.
> +For the design document refer to docs/devel/qemu-multiprocess.
> +
> +1) Configuration
> +----------------
> +
> +To enable support for multi-process add --enable-mpqemu
> +to the list of options for the "configure" script.
> +
> +
> +2) Usage
> +--------
> +
> +Multi-process QEMU requires an orchestrator to launch. Please refer to a
> +light-weight python based orchestrator for mpqemu in
> +scripts/mpqemu-launcher.py to lauch QEMU in multi-process mode.
> +
> +scripts/mpqemu-launcher-perf-mode.py launches in "perf" mode. In this mode,
> +the same QEMU process connects to multiple remote devices, each emulated in
> +a separate process.
> +
> +As of now, we only support the emulation of lsi53c895a in a separate process.
> +
> +Following is a description of command-line used to launch mpqemu.
> +
> +* Orchestrator:
> +
> + - The Orchestrator creates a unix socketpair
> +
> + - It launches the remote process and passes one of the
> + sockets to it via command-line.
> +
> + - It then launches QEMU and specifies the other socket as an option
> + to the Proxy device object
> +
> +* Remote Process:
> +
> + - The first command-line option in the remote process is one of the
> + sockets created by the Orchestrator
> +
> + - The remaining options are no different from how one launches QEMU with
> + devices. The only other requirement is each PCI device must have a
> + unique ID specified to it. This is needed to pair remote device with the
> + Proxy object.
> +
> + - Example command-line for the remote process is as follows:
> +
> + /usr/bin/qemu-scsu-dev 4 \
> + -device lsi53c895a,id=lsi0 \
> + -drive id=drive_image2,file=/build/ol7-nvme-test-1.qcow2 \
> + -device scsi-hd,id=drive2,drive=drive_image2,bus=lsi0.0,scsi-id=0
> +
> +* QEMU:
> +
> + - Since parts of the RAM are shared between QEMU & remote process, a
> + memory-backend-memfd is required to facilitate this, as follows:
> +
> + -object memory-backend-memfd,id=mem,size=2G
> +
> + - A "pci-proxy-dev" device is created for each of the PCI devices emulated
> + in the remote process. A "socket" sub-option specifies the other end of
> + unix channel created by orchestrator. The "id" sub-option must be specified
> + and should be the same as the "id" specified for the remote PCI device
> +
> + - Example commandline for QEMU is as follows:
> +
> + -device pci-proxy-dev,id=lsi0,socket=3
> +
> +* Monitor / QMP:
> +
> + - The remote process supports QEMU monitor. It could be specified using the
> + "-monitor" or "-qmp" command-line options
> +
> + - As an example, one could connect to the monitor by adding the following
> + to the command-line of the remote process
> +
> + -monitor unix:/home/qmp-sock,server,nowait
> +
> + - The user could connect to the monitor using the qmp script or using
> + "socat" as outlined below:
> +
> + socat /home/qmp-sock stdio
> diff --git a/scripts/mpqemu-launcher-perf-mode.py b/scripts/mpqemu-launcher-perf-mode.py
> new file mode 100755
> index 0000000000..2733424c76
> --- /dev/null
> +++ b/scripts/mpqemu-launcher-perf-mode.py
> @@ -0,0 +1,92 @@
> +#!/usr/bin/env python3
> +
> +import socket
> +import os
> +import subprocess
> +import time
> +
> +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> +
> +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> +
> +proxy_1, remote_1 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +proxy_2, remote_2 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +proxy_3, remote_3 = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +
> +remote_cmd_1 = [ PROC_REMOTE, \
> + str(remote_1.fileno()), \
> + '-device', 'lsi53c895a,id=lsi1', \
> + '-drive', 'id=drive_image1,' \
> + 'file=/build/ol7-nvme-test-1.qcow2', \
> + '-device', 'scsi-hd,id=drive1,drive=drive_image1,' \
> + 'bus=lsi1.0,scsi-id=0', \
> + ]
> +
> +remote_cmd_2 = [ PROC_REMOTE, \
> + str(remote_2.fileno()), \
> + '-device', 'lsi53c895a,id=lsi2', \
> + '-drive', 'id=drive_image2,' \
> + 'file=/build/ol7-nvme-test-2.qcow2', \
> + '-device', 'scsi-hd,id=drive2,drive=drive_image2,' \
> + 'bus=lsi2.0,scsi-id=0' \
> + ]
> +
> +remote_cmd_3 = [ PROC_REMOTE, \
> + str(remote_3.fileno()), \
> + '-device', 'lsi53c895a,id=lsi3', \
> + '-drive', 'id=drive_image3,' \
> + 'file=/build/ol7-nvme-test-3.qcow2', \
> + '-device', 'scsi-hd,id=drive3,drive=drive_image3,' \
> + 'bus=lsi3.0,scsi-id=0' \
> + ]
> +
> +proxy_cmd = [ PROC_QEMU, \
> + '-name', 'OL7.4', \
> + '-machine', 'q35,accel=kvm', \
> + '-smp', 'sockets=1,cores=1,threads=1', \
> + '-m', '2048', \
> + '-object', 'memory-backend-memfd,id=sysmem-file,size=2G', \
> + '-numa', 'node,memdev=sysmem-file', \
> + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0', \
> + '-drive', 'id=drive_image1,if=none,format=qcow2,' \
> + 'file=/home/ol7-hdd-1.qcow2', \
> + '-device', 'scsi-hd,id=image1,drive=drive_image1,' \
> + 'bus=virtio_scsi_pci0.0', \
> + '-boot', 'd', \
> + '-vnc', ':0', \
> + '-device', 'pci-proxy-dev,id=lsi1,' \
> + 'socket='+str(proxy_1.fileno()), \
> + '-device', 'pci-proxy-dev,id=lsi2,' \
> + 'socket='+str(proxy_2.fileno()), \
> + '-device', 'pci-proxy-dev,id=lsi3,' \
> + 'socket='+str(proxy_3.fileno()) \
> + ]
> +
> +
> +pid = os.fork();
> +if pid == 0:
> + # In remote_1
> + print('Launching Remote process 1');
> + process = subprocess.Popen(remote_cmd_1, pass_fds=[remote_1.fileno()])
> + os._exit(0)
> +
> +
> +pid = os.fork();
> +if pid == 0:
> + # In remote_2
> + print('Launching Remote process 2');
> + process = subprocess.Popen(remote_cmd_2, pass_fds=[remote_2.fileno()])
> + os._exit(0)
> +
> +
> +pid = os.fork();
> +if pid == 0:
> + # In remote_3
> + print('Launching Remote process 3');
> + process = subprocess.Popen(remote_cmd_3, pass_fds=[remote_3.fileno()])
> + os._exit(0)
> +
> +
> +print('Launching Proxy process');
> +process = subprocess.Popen(proxy_cmd, pass_fds=[proxy_1.fileno(), \
> + proxy_2.fileno(), proxy_3.fileno()])
> diff --git a/scripts/mpqemu-launcher.py b/scripts/mpqemu-launcher.py
> new file mode 100755
> index 0000000000..81e370663e
> --- /dev/null
> +++ b/scripts/mpqemu-launcher.py
> @@ -0,0 +1,53 @@
> +#!/usr/bin/env python3
> +import socket
> +import os
> +import subprocess
> +import time
> +
> +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> +
> +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> +
> +proxy, remote = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> +
> +remote_cmd = [ PROC_REMOTE, \
> + str(remote.fileno()), \
> + '-device', 'lsi53c895a,id=lsi1', \
> + '-drive', 'id=drive_image1,file=/build/ol7-nvme-test-1.qcow2', \
> + '-device', 'scsi-hd,id=drive1,drive=drive_image1,bus=lsi1.0,' \
> + 'scsi-id=0', \
> + '-device', 'lsi53c895a,id=lsi2', \
> + '-drive', 'id=drive_image2,file=/build/ol7-nvme-test-2.qcow2', \
> + '-device', 'scsi-hd,id=drive2,drive=drive_image2,bus=lsi2.0,' \
> + 'scsi-id=0' \
> + ]
> +
> +proxy_cmd = [ PROC_QEMU, \
> + '-name', 'OL7.4', \
> + '-machine', 'q35,accel=kvm', \
> + '-smp', 'sockets=1,cores=1,threads=1', \
> + '-m', '2048', \
> + '-object', 'memory-backend-memfd,id=sysmem-file,size=2G', \
> + '-numa', 'node,memdev=sysmem-file', \
> + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0', \
> + '-drive', 'id=drive_image1,if=none,format=qcow2,' \
> + 'file=/home/ol7-hdd-1.qcow2', \
> + '-device', 'scsi-hd,id=image1,drive=drive_image1,' \
> + 'bus=virtio_scsi_pci0.0', \
> + '-boot', 'd', \
> + '-vnc', ':0', \
> + '-device', 'pci-proxy-dev,id=lsi1,socket='+str(proxy.fileno()), \
> + '-device', 'pci-proxy-dev,id=lsi2,socket='+str(proxy.fileno()) \
> + ]
> +
> +
> +pid = os.fork();
> +
> +if pid:
> + # In Proxy
> + print('Launching QEMU with Proxy object');
> + process = subprocess.Popen(proxy_cmd, pass_fds=[proxy.fileno()])
> +else:
> + # In remote
> + print('Launching Remote process');
> + process = subprocess.Popen(remote_cmd, pass_fds=[remote.fileno()])
> --
> 2.25.GIT
>
>
>
>
> --
> 此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 06/36] monitor: destaticize HMP commands
2020-04-23 14:14 ` Philippe Mathieu-Daudé
@ 2020-04-23 15:07 ` Jag Raman
2020-04-23 15:58 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 94+ messages in thread
From: Jag Raman @ 2020-04-23 15:07 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Elena Ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha, pbonzini,
rth, kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
> On Apr 23, 2020, at 10:14 AM, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>
> Why 'destaticize HMP commands’?
Hi Philippe,
Both QEMU & the remote process links the QMP code. QEMU uses
all of the QMP commands, whereas, the remote process only uses a
subset of this. Therefore, the ‘static’ functions which don’t have a
reference cause build errors (like defined but not used). Therefore,
we decided to destaticize the ones that are causing the build failure.
On a different note, Dave had previously suggested destacizing only the
HMP functions used by the remote process. However, we found out that this is
not possible because without all these functions, the build error still reproduces.
We did confirm that all the functions we have destaticized are necessary to
help with build of the remote process.
Thank you very much!
--
Jag
>
> On 4/23/20 6:13 AM, elena.ufimtseva@oracle.com wrote:
>> From: Jagannathan Raman <jag.raman@oracle.com>
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>> ---
>> hmp-commands.hx | 4 +-
>> monitor/misc.c | 76 +++++++++++++++++++-------------------
>> monitor/monitor-internal.h | 38 +++++++++++++++++++
>> 3 files changed, 78 insertions(+), 40 deletions(-)
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 06/36] monitor: destaticize HMP commands
2020-04-23 15:07 ` Jag Raman
@ 2020-04-23 15:58 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 94+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-23 15:58 UTC (permalink / raw)
To: Jag Raman
Cc: Elena Ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha, pbonzini,
rth, kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
On 4/23/20 5:07 PM, Jag Raman wrote:
>> On Apr 23, 2020, at 10:14 AM, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>>
>> Why 'destaticize HMP commands’?
>
> Hi Philippe,
>
> Both QEMU & the remote process links the QMP code. QEMU uses
> all of the QMP commands, whereas, the remote process only uses a
> subset of this. Therefore, the ‘static’ functions which don’t have a
> reference cause build errors (like defined but not used). Therefore,
> we decided to destaticize the ones that are causing the build failure.
If you explain it, it is understandable. Worth a note in the commit
description then :)
>
> On a different note, Dave had previously suggested destacizing only the
> HMP functions used by the remote process. However, we found out that this is
> not possible because without all these functions, the build error still reproduces.
> We did confirm that all the functions we have destaticized are necessary to
> help with build of the remote process.
>
> Thank you very much!
> --
> Jag
>
>>
>> On 4/23/20 6:13 AM, elena.ufimtseva@oracle.com wrote:
>>> From: Jagannathan Raman <jag.raman@oracle.com>
>>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>>> ---
>>> hmp-commands.hx | 4 +-
>>> monitor/misc.c | 76 +++++++++++++++++++-------------------
>>> monitor/monitor-internal.h | 38 +++++++++++++++++++
>>> 3 files changed, 78 insertions(+), 40 deletions(-)
>>
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 36/36] multi-process: add configure and usage information
2020-04-23 15:01 ` Jag Raman
@ 2020-04-23 22:56 ` 罗勇刚(Yonggang Luo)
2020-04-24 0:34 ` 罗勇刚(Yonggang Luo)
1 sibling, 0 replies; 94+ messages in thread
From: 罗勇刚(Yonggang Luo) @ 2020-04-23 22:56 UTC (permalink / raw)
To: Jag Raman
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, Felipe Franciosi,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
pbonzini, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 13159 bytes --]
On Thu, Apr 23, 2020 at 11:03 PM Jag Raman <jag.raman@oracle.com> wrote:
>
>
> > On Apr 23, 2020, at 9:54 AM, 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
> wrote:
> >
> > Does multi-process support on Windows?
> > I found it use mmap and unix socket for inter-process communication,
> that may not support under Windows.
>
> Hi Yonggang,
>
> We have only tested this on Linux till now. Are you using QEMU with
> Windows?
>
Yeap, I am using QEMU with windows.
>
> > And also, can the python script be replaced by C implementation?
>
> The functionality in the python script would eventually move to libvirt.
> The python
> script is a temporary measure.
>
> Does that means without libvirt, the QEMU can not be called directly?
> Thank you very much!
> —
> Jag
>
> >
> > On Thu, Apr 23, 2020 at 12:38 PM <elena.ufimtseva@oracle.com> wrote:
> > From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> >
> > Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> > Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> > Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> > ---
> > MAINTAINERS | 2 +
> > docs/multi-process.rst | 85 +++++++++++++++++++++++++
> > scripts/mpqemu-launcher-perf-mode.py | 92 ++++++++++++++++++++++++++++
> > scripts/mpqemu-launcher.py | 53 ++++++++++++++++
> > 4 files changed, 232 insertions(+)
> > create mode 100644 docs/multi-process.rst
> > create mode 100755 scripts/mpqemu-launcher-perf-mode.py
> > create mode 100755 scripts/mpqemu-launcher.py
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ed48615e15..8ff3bfae6a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2880,6 +2880,8 @@ F: remote/iohub.c
> > F: remote/remote-opts.h
> > F: remote/remote-opts.c
> > F: docs/devel/multi-process.rst
> > +F: scripts/mpqemu-launcher.py
> > +F: scripts/mpqemu-launcher-perf-mode.py
> >
> > Build and test automation
> > -------------------------
> > diff --git a/docs/multi-process.rst b/docs/multi-process.rst
> > new file mode 100644
> > index 0000000000..8387d6c691
> > --- /dev/null
> > +++ b/docs/multi-process.rst
> > @@ -0,0 +1,85 @@
> > +Multi-process QEMU
> > +==================
> > +
> > +This document describes how to configure and use multi-process qemu.
> > +For the design document refer to docs/devel/qemu-multiprocess.
> > +
> > +1) Configuration
> > +----------------
> > +
> > +To enable support for multi-process add --enable-mpqemu
> > +to the list of options for the "configure" script.
> > +
> > +
> > +2) Usage
> > +--------
> > +
> > +Multi-process QEMU requires an orchestrator to launch. Please refer to a
> > +light-weight python based orchestrator for mpqemu in
> > +scripts/mpqemu-launcher.py to lauch QEMU in multi-process mode.
> > +
> > +scripts/mpqemu-launcher-perf-mode.py launches in "perf" mode. In this
> mode,
> > +the same QEMU process connects to multiple remote devices, each
> emulated in
> > +a separate process.
> > +
> > +As of now, we only support the emulation of lsi53c895a in a separate
> process.
> > +
> > +Following is a description of command-line used to launch mpqemu.
> > +
> > +* Orchestrator:
> > +
> > + - The Orchestrator creates a unix socketpair
> > +
> > + - It launches the remote process and passes one of the
> > + sockets to it via command-line.
> > +
> > + - It then launches QEMU and specifies the other socket as an option
> > + to the Proxy device object
> > +
> > +* Remote Process:
> > +
> > + - The first command-line option in the remote process is one of the
> > + sockets created by the Orchestrator
> > +
> > + - The remaining options are no different from how one launches QEMU
> with
> > + devices. The only other requirement is each PCI device must have a
> > + unique ID specified to it. This is needed to pair remote device
> with the
> > + Proxy object.
> > +
> > + - Example command-line for the remote process is as follows:
> > +
> > + /usr/bin/qemu-scsu-dev 4
> \
> > + -device lsi53c895a,id=lsi0
> \
> > + -drive id=drive_image2,file=/build/ol7-nvme-test-1.qcow2
> \
> > + -device scsi-hd,id=drive2,drive=drive_image2,bus=lsi0.0,scsi-id=0
> > +
> > +* QEMU:
> > +
> > + - Since parts of the RAM are shared between QEMU & remote process, a
> > + memory-backend-memfd is required to facilitate this, as follows:
> > +
> > + -object memory-backend-memfd,id=mem,size=2G
> > +
> > + - A "pci-proxy-dev" device is created for each of the PCI devices
> emulated
> > + in the remote process. A "socket" sub-option specifies the other
> end of
> > + unix channel created by orchestrator. The "id" sub-option must be
> specified
> > + and should be the same as the "id" specified for the remote PCI
> device
> > +
> > + - Example commandline for QEMU is as follows:
> > +
> > + -device pci-proxy-dev,id=lsi0,socket=3
> > +
> > +* Monitor / QMP:
> > +
> > + - The remote process supports QEMU monitor. It could be specified
> using the
> > + "-monitor" or "-qmp" command-line options
> > +
> > + - As an example, one could connect to the monitor by adding the
> following
> > + to the command-line of the remote process
> > +
> > + -monitor unix:/home/qmp-sock,server,nowait
> > +
> > + - The user could connect to the monitor using the qmp script or using
> > + "socat" as outlined below:
> > +
> > + socat /home/qmp-sock stdio
> > diff --git a/scripts/mpqemu-launcher-perf-mode.py
> b/scripts/mpqemu-launcher-perf-mode.py
> > new file mode 100755
> > index 0000000000..2733424c76
> > --- /dev/null
> > +++ b/scripts/mpqemu-launcher-perf-mode.py
> > @@ -0,0 +1,92 @@
> > +#!/usr/bin/env python3
> > +
> > +import socket
> > +import os
> > +import subprocess
> > +import time
> > +
> > +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> > +
> > +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> > +
> > +proxy_1, remote_1 = socket.socketpair(socket.AF_UNIX,
> socket.SOCK_STREAM)
> > +proxy_2, remote_2 = socket.socketpair(socket.AF_UNIX,
> socket.SOCK_STREAM)
> > +proxy_3, remote_3 = socket.socketpair(socket.AF_UNIX,
> socket.SOCK_STREAM)
> > +
> > +remote_cmd_1 = [ PROC_REMOTE,
> \
> > + str(remote_1.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi1',
> \
> > + '-drive', 'id=drive_image1,'
> \
> > + 'file=/build/ol7-nvme-test-1.qcow2',
> \
> > + '-device', 'scsi-hd,id=drive1,drive=drive_image1,'
> \
> > + 'bus=lsi1.0,scsi-id=0',
> \
> > + ]
> > +
> > +remote_cmd_2 = [ PROC_REMOTE,
> \
> > + str(remote_2.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi2',
> \
> > + '-drive', 'id=drive_image2,'
> \
> > + 'file=/build/ol7-nvme-test-2.qcow2',
> \
> > + '-device', 'scsi-hd,id=drive2,drive=drive_image2,'
> \
> > + 'bus=lsi2.0,scsi-id=0'
> \
> > + ]
> > +
> > +remote_cmd_3 = [ PROC_REMOTE,
> \
> > + str(remote_3.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi3',
> \
> > + '-drive', 'id=drive_image3,'
> \
> > + 'file=/build/ol7-nvme-test-3.qcow2',
> \
> > + '-device', 'scsi-hd,id=drive3,drive=drive_image3,'
> \
> > + 'bus=lsi3.0,scsi-id=0'
> \
> > + ]
> > +
> > +proxy_cmd = [ PROC_QEMU,
> \
> > + '-name', 'OL7.4',
> \
> > + '-machine', 'q35,accel=kvm',
> \
> > + '-smp', 'sockets=1,cores=1,threads=1',
> \
> > + '-m', '2048',
> \
> > + '-object',
> 'memory-backend-memfd,id=sysmem-file,size=2G', \
> > + '-numa', 'node,memdev=sysmem-file',
> \
> > + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0',
> \
> > + '-drive', 'id=drive_image1,if=none,format=qcow2,'
> \
> > + 'file=/home/ol7-hdd-1.qcow2',
> \
> > + '-device', 'scsi-hd,id=image1,drive=drive_image1,'
> \
> > + 'bus=virtio_scsi_pci0.0',
> \
> > + '-boot', 'd',
> \
> > + '-vnc', ':0',
> \
> > + '-device', 'pci-proxy-dev,id=lsi1,'
> \
> > + 'socket='+str(proxy_1.fileno()),
> \
> > + '-device', 'pci-proxy-dev,id=lsi2,'
> \
> > + 'socket='+str(proxy_2.fileno()),
> \
> > + '-device', 'pci-proxy-dev,id=lsi3,'
> \
> > + 'socket='+str(proxy_3.fileno())
> \
> > + ]
> > +
> > +
> > +pid = os.fork();
> > +if pid == 0:
> > + # In remote_1
> > + print('Launching Remote process 1');
> > + process = subprocess.Popen(remote_cmd_1,
> pass_fds=[remote_1.fileno()])
> > + os._exit(0)
> > +
> > +
> > +pid = os.fork();
> > +if pid == 0:
> > + # In remote_2
> > + print('Launching Remote process 2');
> > + process = subprocess.Popen(remote_cmd_2,
> pass_fds=[remote_2.fileno()])
> > + os._exit(0)
> > +
> > +
> > +pid = os.fork();
> > +if pid == 0:
> > + # In remote_3
> > + print('Launching Remote process 3');
> > + process = subprocess.Popen(remote_cmd_3,
> pass_fds=[remote_3.fileno()])
> > + os._exit(0)
> > +
> > +
> > +print('Launching Proxy process');
> > +process = subprocess.Popen(proxy_cmd, pass_fds=[proxy_1.fileno(),
> \
> > + proxy_2.fileno(), proxy_3.fileno()])
> > diff --git a/scripts/mpqemu-launcher.py b/scripts/mpqemu-launcher.py
> > new file mode 100755
> > index 0000000000..81e370663e
> > --- /dev/null
> > +++ b/scripts/mpqemu-launcher.py
> > @@ -0,0 +1,53 @@
> > +#!/usr/bin/env python3
> > +import socket
> > +import os
> > +import subprocess
> > +import time
> > +
> > +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> > +
> > +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> > +
> > +proxy, remote = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> > +
> > +remote_cmd = [ PROC_REMOTE,
> \
> > + str(remote.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi1',
> \
> > + '-drive',
> 'id=drive_image1,file=/build/ol7-nvme-test-1.qcow2', \
> > + '-device',
> 'scsi-hd,id=drive1,drive=drive_image1,bus=lsi1.0,' \
> > + 'scsi-id=0',
> \
> > + '-device', 'lsi53c895a,id=lsi2',
> \
> > + '-drive',
> 'id=drive_image2,file=/build/ol7-nvme-test-2.qcow2', \
> > + '-device',
> 'scsi-hd,id=drive2,drive=drive_image2,bus=lsi2.0,' \
> > + 'scsi-id=0'
> \
> > + ]
> > +
> > +proxy_cmd = [ PROC_QEMU,
> \
> > + '-name', 'OL7.4',
> \
> > + '-machine', 'q35,accel=kvm',
> \
> > + '-smp', 'sockets=1,cores=1,threads=1',
> \
> > + '-m', '2048',
> \
> > + '-object',
> 'memory-backend-memfd,id=sysmem-file,size=2G', \
> > + '-numa', 'node,memdev=sysmem-file',
> \
> > + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0',
> \
> > + '-drive', 'id=drive_image1,if=none,format=qcow2,'
> \
> > + 'file=/home/ol7-hdd-1.qcow2',
> \
> > + '-device', 'scsi-hd,id=image1,drive=drive_image1,'
> \
> > + 'bus=virtio_scsi_pci0.0',
> \
> > + '-boot', 'd',
> \
> > + '-vnc', ':0',
> \
> > + '-device',
> 'pci-proxy-dev,id=lsi1,socket='+str(proxy.fileno()), \
> > + '-device',
> 'pci-proxy-dev,id=lsi2,socket='+str(proxy.fileno()) \
> > + ]
> > +
> > +
> > +pid = os.fork();
> > +
> > +if pid:
> > + # In Proxy
> > + print('Launching QEMU with Proxy object');
> > + process = subprocess.Popen(proxy_cmd, pass_fds=[proxy.fileno()])
> > +else:
> > + # In remote
> > + print('Launching Remote process');
> > + process = subprocess.Popen(remote_cmd, pass_fds=[remote.fileno()])
> > --
> > 2.25.GIT
> >
> >
> >
> >
> > --
> > 此致
> > 礼
> > 罗勇刚
> > Yours
> > sincerely,
> > Yonggang Luo
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
[-- Attachment #2: Type: text/html, Size: 19729 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 36/36] multi-process: add configure and usage information
2020-04-23 15:01 ` Jag Raman
2020-04-23 22:56 ` 罗勇刚(Yonggang Luo)
@ 2020-04-24 0:34 ` 罗勇刚(Yonggang Luo)
1 sibling, 0 replies; 94+ messages in thread
From: 罗勇刚(Yonggang Luo) @ 2020-04-24 0:34 UTC (permalink / raw)
To: Jag Raman
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, Felipe Franciosi,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
pbonzini, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 13237 bytes --]
On Thu, Apr 23, 2020 at 11:03 PM Jag Raman <jag.raman@oracle.com> wrote:
>
>
> > On Apr 23, 2020, at 9:54 AM, 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com>
> wrote:
> >
> > Does multi-process support on Windows?
> > I found it use mmap and unix socket for inter-process communication,
> that may not support under Windows.
>
> Hi Yonggang,
>
> We have only tested this on Linux till now. Are you using QEMU with
> Windows?
>
> > And also, can the python script be replaced by C implementation?
>
> The functionality in the python script would eventually move to libvirt.
> The python
> script is a temporary measure.
>
> I suggest use qemu as the driver like clang-cl, we preseve the options
currently avaiable in qemu
and then starting remote process by qemu directly, so we libvirt need to
lauch with qemu
> Thank you very much!
> —
> Jag
>
> >
> > On Thu, Apr 23, 2020 at 12:38 PM <elena.ufimtseva@oracle.com> wrote:
> > From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> >
> > Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> > Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> > Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> > ---
> > MAINTAINERS | 2 +
> > docs/multi-process.rst | 85 +++++++++++++++++++++++++
> > scripts/mpqemu-launcher-perf-mode.py | 92 ++++++++++++++++++++++++++++
> > scripts/mpqemu-launcher.py | 53 ++++++++++++++++
> > 4 files changed, 232 insertions(+)
> > create mode 100644 docs/multi-process.rst
> > create mode 100755 scripts/mpqemu-launcher-perf-mode.py
> > create mode 100755 scripts/mpqemu-launcher.py
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ed48615e15..8ff3bfae6a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2880,6 +2880,8 @@ F: remote/iohub.c
> > F: remote/remote-opts.h
> > F: remote/remote-opts.c
> > F: docs/devel/multi-process.rst
> > +F: scripts/mpqemu-launcher.py
> > +F: scripts/mpqemu-launcher-perf-mode.py
> >
> > Build and test automation
> > -------------------------
> > diff --git a/docs/multi-process.rst b/docs/multi-process.rst
> > new file mode 100644
> > index 0000000000..8387d6c691
> > --- /dev/null
> > +++ b/docs/multi-process.rst
> > @@ -0,0 +1,85 @@
> > +Multi-process QEMU
> > +==================
> > +
> > +This document describes how to configure and use multi-process qemu.
> > +For the design document refer to docs/devel/qemu-multiprocess.
> > +
> > +1) Configuration
> > +----------------
> > +
> > +To enable support for multi-process add --enable-mpqemu
> > +to the list of options for the "configure" script.
> > +
> > +
> > +2) Usage
> > +--------
> > +
> > +Multi-process QEMU requires an orchestrator to launch. Please refer to a
> > +light-weight python based orchestrator for mpqemu in
> > +scripts/mpqemu-launcher.py to lauch QEMU in multi-process mode.
> > +
> > +scripts/mpqemu-launcher-perf-mode.py launches in "perf" mode. In this
> mode,
> > +the same QEMU process connects to multiple remote devices, each
> emulated in
> > +a separate process.
> > +
> > +As of now, we only support the emulation of lsi53c895a in a separate
> process.
> > +
> > +Following is a description of command-line used to launch mpqemu.
> > +
> > +* Orchestrator:
> > +
> > + - The Orchestrator creates a unix socketpair
> > +
> > + - It launches the remote process and passes one of the
> > + sockets to it via command-line.
> > +
> > + - It then launches QEMU and specifies the other socket as an option
> > + to the Proxy device object
> > +
> > +* Remote Process:
> > +
> > + - The first command-line option in the remote process is one of the
> > + sockets created by the Orchestrator
> > +
> > + - The remaining options are no different from how one launches QEMU
> with
> > + devices. The only other requirement is each PCI device must have a
> > + unique ID specified to it. This is needed to pair remote device
> with the
> > + Proxy object.
> > +
> > + - Example command-line for the remote process is as follows:
> > +
> > + /usr/bin/qemu-scsu-dev 4
> \
> > + -device lsi53c895a,id=lsi0
> \
> > + -drive id=drive_image2,file=/build/ol7-nvme-test-1.qcow2
> \
> > + -device scsi-hd,id=drive2,drive=drive_image2,bus=lsi0.0,scsi-id=0
> > +
> > +* QEMU:
> > +
> > + - Since parts of the RAM are shared between QEMU & remote process, a
> > + memory-backend-memfd is required to facilitate this, as follows:
> > +
> > + -object memory-backend-memfd,id=mem,size=2G
> > +
> > + - A "pci-proxy-dev" device is created for each of the PCI devices
> emulated
> > + in the remote process. A "socket" sub-option specifies the other
> end of
> > + unix channel created by orchestrator. The "id" sub-option must be
> specified
> > + and should be the same as the "id" specified for the remote PCI
> device
> > +
> > + - Example commandline for QEMU is as follows:
> > +
> > + -device pci-proxy-dev,id=lsi0,socket=3
> > +
> > +* Monitor / QMP:
> > +
> > + - The remote process supports QEMU monitor. It could be specified
> using the
> > + "-monitor" or "-qmp" command-line options
> > +
> > + - As an example, one could connect to the monitor by adding the
> following
> > + to the command-line of the remote process
> > +
> > + -monitor unix:/home/qmp-sock,server,nowait
> > +
> > + - The user could connect to the monitor using the qmp script or using
> > + "socat" as outlined below:
> > +
> > + socat /home/qmp-sock stdio
> > diff --git a/scripts/mpqemu-launcher-perf-mode.py
> b/scripts/mpqemu-launcher-perf-mode.py
> > new file mode 100755
> > index 0000000000..2733424c76
> > --- /dev/null
> > +++ b/scripts/mpqemu-launcher-perf-mode.py
> > @@ -0,0 +1,92 @@
> > +#!/usr/bin/env python3
> > +
> > +import socket
> > +import os
> > +import subprocess
> > +import time
> > +
> > +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> > +
> > +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> > +
> > +proxy_1, remote_1 = socket.socketpair(socket.AF_UNIX,
> socket.SOCK_STREAM)
> > +proxy_2, remote_2 = socket.socketpair(socket.AF_UNIX,
> socket.SOCK_STREAM)
> > +proxy_3, remote_3 = socket.socketpair(socket.AF_UNIX,
> socket.SOCK_STREAM)
> > +
> > +remote_cmd_1 = [ PROC_REMOTE,
> \
> > + str(remote_1.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi1',
> \
> > + '-drive', 'id=drive_image1,'
> \
> > + 'file=/build/ol7-nvme-test-1.qcow2',
> \
> > + '-device', 'scsi-hd,id=drive1,drive=drive_image1,'
> \
> > + 'bus=lsi1.0,scsi-id=0',
> \
> > + ]
> > +
> > +remote_cmd_2 = [ PROC_REMOTE,
> \
> > + str(remote_2.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi2',
> \
> > + '-drive', 'id=drive_image2,'
> \
> > + 'file=/build/ol7-nvme-test-2.qcow2',
> \
> > + '-device', 'scsi-hd,id=drive2,drive=drive_image2,'
> \
> > + 'bus=lsi2.0,scsi-id=0'
> \
> > + ]
> > +
> > +remote_cmd_3 = [ PROC_REMOTE,
> \
> > + str(remote_3.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi3',
> \
> > + '-drive', 'id=drive_image3,'
> \
> > + 'file=/build/ol7-nvme-test-3.qcow2',
> \
> > + '-device', 'scsi-hd,id=drive3,drive=drive_image3,'
> \
> > + 'bus=lsi3.0,scsi-id=0'
> \
> > + ]
> > +
> > +proxy_cmd = [ PROC_QEMU,
> \
> > + '-name', 'OL7.4',
> \
> > + '-machine', 'q35,accel=kvm',
> \
> > + '-smp', 'sockets=1,cores=1,threads=1',
> \
> > + '-m', '2048',
> \
> > + '-object',
> 'memory-backend-memfd,id=sysmem-file,size=2G', \
> > + '-numa', 'node,memdev=sysmem-file',
> \
> > + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0',
> \
> > + '-drive', 'id=drive_image1,if=none,format=qcow2,'
> \
> > + 'file=/home/ol7-hdd-1.qcow2',
> \
> > + '-device', 'scsi-hd,id=image1,drive=drive_image1,'
> \
> > + 'bus=virtio_scsi_pci0.0',
> \
> > + '-boot', 'd',
> \
> > + '-vnc', ':0',
> \
> > + '-device', 'pci-proxy-dev,id=lsi1,'
> \
> > + 'socket='+str(proxy_1.fileno()),
> \
> > + '-device', 'pci-proxy-dev,id=lsi2,'
> \
> > + 'socket='+str(proxy_2.fileno()),
> \
> > + '-device', 'pci-proxy-dev,id=lsi3,'
> \
> > + 'socket='+str(proxy_3.fileno())
> \
> > + ]
> > +
> > +
> > +pid = os.fork();
> > +if pid == 0:
> > + # In remote_1
> > + print('Launching Remote process 1');
> > + process = subprocess.Popen(remote_cmd_1,
> pass_fds=[remote_1.fileno()])
> > + os._exit(0)
> > +
> > +
> > +pid = os.fork();
> > +if pid == 0:
> > + # In remote_2
> > + print('Launching Remote process 2');
> > + process = subprocess.Popen(remote_cmd_2,
> pass_fds=[remote_2.fileno()])
> > + os._exit(0)
> > +
> > +
> > +pid = os.fork();
> > +if pid == 0:
> > + # In remote_3
> > + print('Launching Remote process 3');
> > + process = subprocess.Popen(remote_cmd_3,
> pass_fds=[remote_3.fileno()])
> > + os._exit(0)
> > +
> > +
> > +print('Launching Proxy process');
> > +process = subprocess.Popen(proxy_cmd, pass_fds=[proxy_1.fileno(),
> \
> > + proxy_2.fileno(), proxy_3.fileno()])
> > diff --git a/scripts/mpqemu-launcher.py b/scripts/mpqemu-launcher.py
> > new file mode 100755
> > index 0000000000..81e370663e
> > --- /dev/null
> > +++ b/scripts/mpqemu-launcher.py
> > @@ -0,0 +1,53 @@
> > +#!/usr/bin/env python3
> > +import socket
> > +import os
> > +import subprocess
> > +import time
> > +
> > +PROC_QEMU='/usr/bin/qemu-system-x86_64'
> > +
> > +PROC_REMOTE='/usr/bin/qemu-scsi-dev'
> > +
> > +proxy, remote = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
> > +
> > +remote_cmd = [ PROC_REMOTE,
> \
> > + str(remote.fileno()),
> \
> > + '-device', 'lsi53c895a,id=lsi1',
> \
> > + '-drive',
> 'id=drive_image1,file=/build/ol7-nvme-test-1.qcow2', \
> > + '-device',
> 'scsi-hd,id=drive1,drive=drive_image1,bus=lsi1.0,' \
> > + 'scsi-id=0',
> \
> > + '-device', 'lsi53c895a,id=lsi2',
> \
> > + '-drive',
> 'id=drive_image2,file=/build/ol7-nvme-test-2.qcow2', \
> > + '-device',
> 'scsi-hd,id=drive2,drive=drive_image2,bus=lsi2.0,' \
> > + 'scsi-id=0'
> \
> > + ]
> > +
> > +proxy_cmd = [ PROC_QEMU,
> \
> > + '-name', 'OL7.4',
> \
> > + '-machine', 'q35,accel=kvm',
> \
> > + '-smp', 'sockets=1,cores=1,threads=1',
> \
> > + '-m', '2048',
> \
> > + '-object',
> 'memory-backend-memfd,id=sysmem-file,size=2G', \
> > + '-numa', 'node,memdev=sysmem-file',
> \
> > + '-device', 'virtio-scsi-pci,id=virtio_scsi_pci0',
> \
> > + '-drive', 'id=drive_image1,if=none,format=qcow2,'
> \
> > + 'file=/home/ol7-hdd-1.qcow2',
> \
> > + '-device', 'scsi-hd,id=image1,drive=drive_image1,'
> \
> > + 'bus=virtio_scsi_pci0.0',
> \
> > + '-boot', 'd',
> \
> > + '-vnc', ':0',
> \
> > + '-device',
> 'pci-proxy-dev,id=lsi1,socket='+str(proxy.fileno()), \
> > + '-device',
> 'pci-proxy-dev,id=lsi2,socket='+str(proxy.fileno()) \
> > + ]
> > +
> > +
> > +pid = os.fork();
> > +
> > +if pid:
> > + # In Proxy
> > + print('Launching QEMU with Proxy object');
> > + process = subprocess.Popen(proxy_cmd, pass_fds=[proxy.fileno()])
> > +else:
> > + # In remote
> > + print('Launching Remote process');
> > + process = subprocess.Popen(remote_cmd, pass_fds=[remote.fileno()])
> > --
> > 2.25.GIT
> >
> >
> >
> >
> > --
> > 此致
> > 礼
> > 罗勇刚
> > Yours
> > sincerely,
> > Yonggang Luo
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
[-- Attachment #2: Type: text/html, Size: 19683 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (35 preceding siblings ...)
2020-04-23 4:14 ` [PATCH RESEND v6 36/36] multi-process: add configure and usage information elena.ufimtseva
@ 2020-04-24 12:48 ` Stefan Hajnoczi
2020-04-24 12:53 ` Daniel P. Berrangé
2020-04-24 12:53 ` Eric Blake
2020-04-28 17:29 ` Stefan Hajnoczi
2020-05-11 14:40 ` Stefan Hajnoczi
38 siblings, 2 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-24 12:48 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]
On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimtseva@oracle.com wrote:
> There is an error in travis-ci build test which does not get reproduced.
>
> TEST iotest-qcow2: 041 [fail]
> QEMU -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64" -nodefaults -display none -accel qtest
> QEMU_IMG -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-img"
> QEMU_IO -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2
> QEMU_NBD -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-nbd"
> IMGFMT -- qcow2 (compat=1.1)
> IMGPROTO -- file
> PLATFORM -- Linux/x86_64 travis-job-fc4e2553-b470-4a8b-812e-a4fcf8ba094f 5.0.0-1031-gcp
> TEST_DIR -- /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch
> SOCK_DIR -- /tmp/tmp.LOmYANt5Od
> SOCKET_SCM_HELPER -- /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/socket_scm_helper
> --- /home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/041.out 2020-04-22 00:17:23.701844698 +0000
> +++ /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/041.out.bad 2020-04-22 00:24:39.234343858 +0000
> @@ -1,5 +1,29 @@
> -..............................................................................................
> +........................FF....................................................................
> +======================================================================
> +FAIL: test_with_other_parent (__main__.TestRepairQuorum)
> +----------------------------------------------------------------------
> +Traceback (most recent call last):
> + File "041", line 1049, in test_with_other_parent
> + self.assert_qmp(result, 'return', {})
> + File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 821, in assert_qmp
> + result = self.dictpath(d, path)
> + File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 797, in dictpath
> + self.fail('failed path traversal for "%s" in "%s"' % (path, str(d)))
> +AssertionError: failed path traversal for "return" in "{'error': {'class': 'GenericError', 'desc': "UNIX socket path '/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch/nbd.sock' is too long"}}"
UNIX Domain Socket paths have to be 108 characters or less. The path in
the failed test case is 110 characters long. You could rename your
branch to "mpqemu" to solve this failure.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-24 12:48 ` [PATCH RESEND v6 00/36] Initial support for multi-process qemu Stefan Hajnoczi
@ 2020-04-24 12:53 ` Daniel P. Berrangé
2020-04-24 12:53 ` Eric Blake
1 sibling, 0 replies; 94+ messages in thread
From: Daniel P. Berrangé @ 2020-04-24 12:53 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon, pbonzini,
rth, kwolf, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
On Fri, Apr 24, 2020 at 01:48:23PM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimtseva@oracle.com wrote:
> > There is an error in travis-ci build test which does not get reproduced.
> >
> > TEST iotest-qcow2: 041 [fail]
> > QEMU -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64" -nodefaults -display none -accel qtest
> > QEMU_IMG -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-img"
> > QEMU_IO -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2
> > QEMU_NBD -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../qemu-nbd"
> > IMGFMT -- qcow2 (compat=1.1)
> > IMGPROTO -- file
> > PLATFORM -- Linux/x86_64 travis-job-fc4e2553-b470-4a8b-812e-a4fcf8ba094f 5.0.0-1031-gcp
> > TEST_DIR -- /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch
> > SOCK_DIR -- /tmp/tmp.LOmYANt5Od
> > SOCKET_SCM_HELPER -- /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/socket_scm_helper
> > --- /home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/041.out 2020-04-22 00:17:23.701844698 +0000
> > +++ /home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/041.out.bad 2020-04-22 00:24:39.234343858 +0000
> > @@ -1,5 +1,29 @@
> > -..............................................................................................
> > +........................FF....................................................................
> > +======================================================================
> > +FAIL: test_with_other_parent (__main__.TestRepairQuorum)
> > +----------------------------------------------------------------------
> > +Traceback (most recent call last):
> > + File "041", line 1049, in test_with_other_parent
> > + self.assert_qmp(result, 'return', {})
> > + File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 821, in assert_qmp
> > + result = self.dictpath(d, path)
> > + File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 797, in dictpath
> > + self.fail('failed path traversal for "%s" in "%s"' % (path, str(d)))
> > +AssertionError: failed path traversal for "return" in "{'error': {'class': 'GenericError', 'desc': "UNIX socket path '/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch/nbd.sock' is too long"}}"
>
> UNIX Domain Socket paths have to be 108 characters or less. The path in
> the failed test case is 110 characters long. You could rename your
> branch to "mpqemu" to solve this failure.
Renaming is a pretty poor band-aid.
We should fix the i/o tests instead, so that they use a scratch dir under
$TMP to store unix sockets needed by tests instead.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-24 12:48 ` [PATCH RESEND v6 00/36] Initial support for multi-process qemu Stefan Hajnoczi
2020-04-24 12:53 ` Daniel P. Berrangé
@ 2020-04-24 12:53 ` Eric Blake
2020-04-24 13:42 ` Max Reitz
1 sibling, 1 reply; 94+ messages in thread
From: Eric Blake @ 2020-04-24 12:53 UTC (permalink / raw)
To: Stefan Hajnoczi, elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, pbonzini, rth,
kwolf, berrange, Max Reitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
On 4/24/20 7:48 AM, Stefan Hajnoczi wrote:
> On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimtseva@oracle.com wrote:
>> There is an error in travis-ci build test which does not get reproduced.
>>
>> TEST iotest-qcow2: 041 [fail]
>> QEMU -- "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64" -nodefaults -display none -accel qtest
>> +Traceback (most recent call last):
>> + File "041", line 1049, in test_with_other_parent
>> + self.assert_qmp(result, 'return', {})
>> + File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 821, in assert_qmp
>> + result = self.dictpath(d, path)
>> + File "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py", line 797, in dictpath
>> + self.fail('failed path traversal for "%s" in "%s"' % (path, str(d)))
>> +AssertionError: failed path traversal for "return" in "{'error': {'class': 'GenericError', 'desc': "UNIX socket path '/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch/nbd.sock' is too long"}}"
>
> UNIX Domain Socket paths have to be 108 characters or less. The path in
> the failed test case is 110 characters long. You could rename your
> branch to "mpqemu" to solve this failure.
We recently fixed the iotests to prefer sticking NBD sockets under
$SOCK_DIR (see commits f0e24942 and friends); did we miss test 41?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 03/36] command-line: refractor parser code
2020-04-23 4:13 ` [PATCH RESEND v6 03/36] command-line: refractor parser code elena.ufimtseva
@ 2020-04-24 12:55 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-24 12:55 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
On Wed, Apr 22, 2020 at 09:13:38PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>
> Refactor command-line parser code so that it could be used by
> other processes as well.
How will qemu-options-wrapper.h be handled for other processes? At the
moment qemu-parse.c cannot be reused because it includes this file for
the options list.
> diff --git a/include/qemu-parse.h b/include/qemu-parse.h
> new file mode 100644
> index 0000000000..156b238db6
> --- /dev/null
> +++ b/include/qemu-parse.h
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
This code is extracted from vl.c so the copyright should be preserved
and not replaced with yours.
You can add yours for changes that have been made.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#ifndef VL_H
> +#define VL_H
#define QEMU_PARSE_H
> +
> +int drive_init_func(void *opaque, QemuOpts *opts, Error **errp);
> +
> +int device_init_func(void *opaque, QemuOpts *opts, Error **errp);
What do drive_init_func() and device_init_func() have to do with
lookup_opt()? I wouldn't expect to see them in this header file.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 05/36] multi-process: Refactor monitor functions out of vl.c
2020-04-23 4:13 ` [PATCH RESEND v6 05/36] multi-process: Refactor monitor " elena.ufimtseva
@ 2020-04-24 13:02 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-24 13:02 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 5074 bytes --]
On Wed, Apr 22, 2020 at 09:13:40PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>
> Some of the initialization helper functions w.r.t monitor
> in vl.c are also used by the remote process. Therefore, these functions
> are refactored into shared files that both QEMU & remote process
> could use.
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
> include/monitor/monitor.h | 3 +++
> monitor/monitor.c | 37 +++++++++++++++++++++++++++++++++++++
> softmmu/vl.c | 35 -----------------------------------
> 3 files changed, 40 insertions(+), 35 deletions(-)
Kevin Wolf recently had to solve a similar problem when introducing
qemu-storage-daemon.
qemu-storage-daemon.c open-codes the command-line parsing instead of
trying to reuse vl.c's code. The vl.c code is old and not very neat,
unless other code depends on it I would suggest writing modern clean
code like Kevin did instead of trying to keep using vl.c code.
>
> diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
> index 1018d754a6..3803e904f2 100644
> --- a/include/monitor/monitor.h
> +++ b/include/monitor/monitor.h
> @@ -48,4 +48,7 @@ int monitor_fdset_dup_fd_add(int64_t fdset_id, int dup_fd);
> void monitor_fdset_dup_fd_remove(int dup_fd);
> int64_t monitor_fdset_dup_fd_find(int dup_fd);
>
> +int mon_init_func(void *opaque, QemuOpts *opts, Error **errp);
> +void monitor_parse(const char *optarg, const char *mode, bool pretty);
> +
> #endif /* MONITOR_H */
> diff --git a/monitor/monitor.c b/monitor/monitor.c
> index 125494410a..88423b38b6 100644
> --- a/monitor/monitor.c
> +++ b/monitor/monitor.c
> @@ -35,6 +35,8 @@
> #include "sysemu/qtest.h"
> #include "sysemu/sysemu.h"
> #include "trace.h"
> +#include "qemu/cutils.h"
> +#include "qemu/config-file.h"
>
> /*
> * To prevent flooding clients, events can be throttled. The
> @@ -611,6 +613,41 @@ void monitor_init_globals_core(void)
> NULL);
> }
>
> +int mon_init_func(void *opaque, QemuOpts *opts, Error **errp)
> +{
> + return monitor_init_opts(opts, errp);
> +}
> +
> +void monitor_parse(const char *optarg, const char *mode, bool pretty)
> +{
> + static int monitor_device_index;
> + QemuOpts *opts;
> + const char *p;
> + char label[32];
> +
> + if (strstart(optarg, "chardev:", &p)) {
> + snprintf(label, sizeof(label), "%s", p);
> + } else {
> + snprintf(label, sizeof(label), "compat_monitor%d",
> + monitor_device_index);
> + opts = qemu_chr_parse_compat(label, optarg, true);
> + if (!opts) {
> + error_report("parse error: %s", optarg);
> + exit(1);
> + }
> + }
> +
> + opts = qemu_opts_create(qemu_find_opts("mon"), label, 1, &error_fatal);
> + qemu_opt_set(opts, "mode", mode, &error_abort);
> + qemu_opt_set(opts, "chardev", label, &error_abort);
> + if (!strcmp(mode, "control")) {
> + qemu_opt_set_bool(opts, "pretty", pretty, &error_abort);
> + } else {
> + assert(pretty == false);
> + }
> + monitor_device_index++;
> +}
> +
> int monitor_init(MonitorOptions *opts, bool allow_hmp, Error **errp)
> {
> Chardev *chr;
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index 6e35f3787d..abc746c1b5 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -2045,41 +2045,6 @@ static int fsdev_init_func(void *opaque, QemuOpts *opts, Error **errp)
> }
> #endif
>
> -static int mon_init_func(void *opaque, QemuOpts *opts, Error **errp)
> -{
> - return monitor_init_opts(opts, errp);
> -}
> -
> -static void monitor_parse(const char *optarg, const char *mode, bool pretty)
> -{
> - static int monitor_device_index = 0;
> - QemuOpts *opts;
> - const char *p;
> - char label[32];
> -
> - if (strstart(optarg, "chardev:", &p)) {
> - snprintf(label, sizeof(label), "%s", p);
> - } else {
> - snprintf(label, sizeof(label), "compat_monitor%d",
> - monitor_device_index);
> - opts = qemu_chr_parse_compat(label, optarg, true);
> - if (!opts) {
> - error_report("parse error: %s", optarg);
> - exit(1);
> - }
> - }
> -
> - opts = qemu_opts_create(qemu_find_opts("mon"), label, 1, &error_fatal);
> - qemu_opt_set(opts, "mode", mode, &error_abort);
> - qemu_opt_set(opts, "chardev", label, &error_abort);
> - if (!strcmp(mode, "control")) {
> - qemu_opt_set_bool(opts, "pretty", pretty, &error_abort);
> - } else {
> - assert(pretty == false);
> - }
> - monitor_device_index++;
> -}
> -
> struct device_config {
> enum {
> DEV_USB, /* -usbdevice */
> --
> 2.25.GIT
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process
2020-04-23 4:13 ` [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process elena.ufimtseva
@ 2020-04-24 13:12 ` Stefan Hajnoczi
2020-04-24 13:47 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-24 13:12 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On Wed, Apr 22, 2020 at 09:13:43PM -0700, elena.ufimtseva@oracle.com wrote:
> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> index f884bb6180..f74c7e927b 100644
> --- a/stubs/Makefile.objs
> +++ b/stubs/Makefile.objs
> @@ -20,6 +20,7 @@ stub-obj-y += migr-blocker.o
> stub-obj-y += change-state-handler.o
> stub-obj-y += monitor.o
> stub-obj-y += monitor-core.o
> +stub-obj-y += get-fd.o
> stub-obj-y += notify-event.o
> stub-obj-y += qtest.o
> stub-obj-y += replay.o
audio.c, vl-stub.c, and xen-mapcache.c are added by this patch but not
added to Makefile.objs? Can they be removed?
This entire patch requires justification. Stubs exist so that common
code can be linked without optional features.
For example, common code may call into kvm but that callback isn't
relevant when building with kvm accelerator support (e.g. say qemu-nbd).
That's where the stub function comes in. It fulfills the dependency
without dragging in the actual kvm accelerator code.
Adding lots of stubs suggests you are building QEMU in a new way that
wasn't done before (this is true and expected for this patch series). I
would like to understand the reason for these stubs though. For
example, why do you need to stub audio?
Without a reason for each of these stubs we have no way of knowing if
they are actually used/needed. Maybe an earlier version of the code
needed it but the latest version of the patch no longer does...
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-24 12:53 ` Eric Blake
@ 2020-04-24 13:42 ` Max Reitz
0 siblings, 0 replies; 94+ messages in thread
From: Max Reitz @ 2020-04-24 13:42 UTC (permalink / raw)
To: Eric Blake, Stefan Hajnoczi, elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, pbonzini, rth,
kwolf, berrange, ross.lagerwall, marcandre.lureau,
thanos.makatos
[-- Attachment #1.1: Type: text/plain, Size: 1706 bytes --]
On 24.04.20 14:53, Eric Blake wrote:
> On 4/24/20 7:48 AM, Stefan Hajnoczi wrote:
>> On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimtseva@oracle.com
>> wrote:
>>> There is an error in travis-ci build test which does not get reproduced.
>>>
>>> TEST iotest-qcow2: 041 [fail]
>>> QEMU --
>>> "/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64"
>>> -nodefaults -display none -accel qtest
>
>>> +Traceback (most recent call last):
>>> + File "041", line 1049, in test_with_other_parent
>>> + self.assert_qmp(result, 'return', {})
>>> + File
>>> "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py",
>>> line 821, in assert_qmp
>>> + result = self.dictpath(d, path)
>>> + File
>>> "/home/travis/build/elena-ufimtseva/qemu-multiprocess/tests/qemu-iotests/iotests.py",
>>> line 797, in dictpath
>>> + self.fail('failed path traversal for "%s" in "%s"' % (path,
>>> str(d)))
>>> +AssertionError: failed path traversal for "return" in "{'error':
>>> {'class': 'GenericError', 'desc': "UNIX socket path
>>> '/home/travis/build/elena-ufimtseva/qemu-multiprocess/out-of-tree/build/dir/tests/qemu-iotests/scratch/nbd.sock'
>>> is too long"}}"
>>
>> UNIX Domain Socket paths have to be 108 characters or less. The path in
>> the failed test case is 110 characters long. You could rename your
>> branch to "mpqemu" to solve this failure.
>
> We recently fixed the iotests to prefer sticking NBD sockets under
> $SOCK_DIR (see commits f0e24942 and friends); did we miss test 41?
Looks more like I broke it. Oops. Will fix.
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process
2020-04-24 13:12 ` Stefan Hajnoczi
@ 2020-04-24 13:47 ` Jag Raman
2020-04-28 16:29 ` Stefan Hajnoczi
0 siblings, 1 reply; 94+ messages in thread
From: Jag Raman @ 2020-04-24 13:47 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, swapnil.ingle, John G Johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, pbonzini, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
> On Apr 24, 2020, at 9:12 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Wed, Apr 22, 2020 at 09:13:43PM -0700, elena.ufimtseva@oracle.com wrote:
>> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
>> index f884bb6180..f74c7e927b 100644
>> --- a/stubs/Makefile.objs
>> +++ b/stubs/Makefile.objs
>> @@ -20,6 +20,7 @@ stub-obj-y += migr-blocker.o
>> stub-obj-y += change-state-handler.o
>> stub-obj-y += monitor.o
>> stub-obj-y += monitor-core.o
>> +stub-obj-y += get-fd.o
>> stub-obj-y += notify-event.o
>> stub-obj-y += qtest.o
>> stub-obj-y += replay.o
>
> audio.c, vl-stub.c, and xen-mapcache.c are added by this patch but not
> added to Makefile.objs? Can they be removed?
Hey Stefan,
Sorry it’s not clear. but these files are referenced in Makefile.target.
>
> This entire patch requires justification. Stubs exist so that common
> code can be linked without optional features.
>
> For example, common code may call into kvm but that callback isn't
> relevant when building with kvm accelerator support (e.g. say qemu-nbd).
> That's where the stub function comes in. It fulfills the dependency
> without dragging in the actual kvm accelerator code.
>
> Adding lots of stubs suggests you are building QEMU in a new way that
> wasn't done before (this is true and expected for this patch series). I
> would like to understand the reason for these stubs though. For
> example, why do you need to stub audio?
These stub functions are only used by the remote process, and not by
QEMU itself.
Our goal is to ensure that the remote process is building the smallest
set of files necessary and these stub functions are necessary to meet
that goal.
For example, the remote process needs to build some of the functions
defined in “hw/core/qdev-properties-system.c”. However, this file
depends on audio.c (references audio_state_by_name()), which is not
needed for the remote process. The alternative to stub functions would
be to compile audio.c into the remote process, but that was not necessary
in our judgement. When the project started out, we spent a lot of time
figuring out which functions/files are necessary for the remote process, and
we stubbed out the ones which are needed to resolve dependency during
compilation, but not needed for functionality.
audio.c is just an example of tens of other places where we needed to
make similar judgements.
Would you prefer if we moved these stub functions into a separate
library (instead of stub-obj-y) which is only linked by the remote process?
--
Jag
>
> Without a reason for each of these stubs we have no way of knowing if
> they are actually used/needed. Maybe an earlier version of the code
> needed it but the latest version of the patch no longer does...
>
> Stefan
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 09/36] multi-process: Add config option for multi-process QEMU
2020-04-23 4:13 ` [PATCH RESEND v6 09/36] multi-process: Add config option for multi-process QEMU elena.ufimtseva
@ 2020-04-24 13:47 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-24 13:47 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Wed, Apr 22, 2020 at 09:13:44PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Add a configuration option to separate multi-process code
>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> ---
> configure | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 10/36] multi-process: build system for remote device process
2020-04-23 4:13 ` [PATCH RESEND v6 10/36] multi-process: build system for remote device process elena.ufimtseva
@ 2020-04-24 15:04 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-24 15:04 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 4817 bytes --]
On Wed, Apr 22, 2020 at 09:13:45PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Modify Makefile to support the building of the remote
> device process. Implements main() function of remote
> device process.
>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> ---
> MAINTAINERS | 8 ++++++
> Makefile | 2 ++
> Makefile.objs | 27 ++++++++++++++++++
> Makefile.target | 61 ++++++++++++++++++++++++++++++++++++++++-
> accel/Makefile.objs | 2 ++
> backends/Makefile.objs | 2 ++
> block/Makefile.objs | 2 ++
> hw/Makefile.objs | 7 +++++
> hw/block/Makefile.objs | 2 ++
> hw/core/Makefile.objs | 18 ++++++++++++
> hw/nvram/Makefile.objs | 2 ++
> hw/pci/Makefile.objs | 4 +++
> hw/scsi/Makefile.objs | 2 ++
> migration/Makefile.objs | 2 ++
> qom/Makefile.objs | 3 ++
> remote/Makefile.objs | 1 +
> remote/remote-main.c | 23 ++++++++++++++++
> stubs/replay.c | 4 +++
> 18 files changed, 171 insertions(+), 1 deletion(-)
> create mode 100644 remote/Makefile.objs
> create mode 100644 remote/remote-main.c
This approach is okay for now but will result in a lot of Makefile
duplication in the long run.
Each hw .o file should specify its dependencies so that qemu-system-*
and the remote executable can link in the needed files. The Kconfig
system can also help with this by enabling/disabling features.
Then the Makefiles don't need to duplicate *-obj-y and remote-pci-*.
> diff --git a/Makefile.objs b/Makefile.objs
> index f29c60c59d..f6654633b4 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -21,6 +21,33 @@ block-obj-$(CONFIG_REPLICATION) += replication.o
>
> block-obj-m = block/
>
> +#########################################################
> +# remote-pci-obj-y is common code used by remote devices
> +
> +remote-pci-obj-$(CONFIG_MPQEMU) += hw/
> +remote-pci-obj-$(CONFIG_MPQEMU) += qom/
> +remote-pci-obj-$(CONFIG_MPQEMU) += backends/
> +remote-pci-obj-$(CONFIG_MPQEMU) += block/
> +remote-pci-obj-$(CONFIG_MPQEMU) += migration/
In the future migration can be split into the QEMU and remote parts.
The remote executable doesn't need all the live migration code.
> +remote-pci-obj-$(CONFIG_MPQEMU) += remote/
> +remote-pci-obj-$(CONFIG_MPQEMU) += accel/
Devices do not execute guest code so they should not need accel/. kvm
and tcg functions were stubbed out earlier in this patch series, so I'm
surprised to see thing being built into the remote executable.
> @@ -121,6 +131,20 @@ LIBS := $(libs_cpu) $(LIBS)
>
> obj-$(CONFIG_PLUGIN) += plugins/
>
> +ifeq ($(TARGET_NAME)-$(CONFIG_MPQEMU)-$(CONFIG_USER_ONLY), x86_64-y-)
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/kvm-stub.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/tcg-stub.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/hax-stub.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += accel/stubs/whpx-stub.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/vl-stub.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/net-stub.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/monitor.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/replay.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/xen-mapcache.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/audio.o
> +remote-pci-tgt-obj-$(CONFIG_MPQEMU) += stubs/monitor.o
> +endif
Stubs don't need to be explicitly included, they should be linked in via
libqemustub.a.
> diff --git a/remote/remote-main.c b/remote/remote-main.c
> new file mode 100644
> index 0000000000..7c0764ad01
> --- /dev/null
> +++ b/remote/remote-main.c
> @@ -0,0 +1,23 @@
> +/*
> + * Remote device initialization
> + *
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +
> +#include <stdio.h>
This is already included by "qemu/osdep.h"
> +
> +#include "qemu/module.h"
> +
> +int main(int argc, char *argv[])
> +{
> + module_call_init(MODULE_INIT_QOM);
> +
> + return 0;
> +}
> diff --git a/stubs/replay.c b/stubs/replay.c
> index 2e3feee6a9..9b53c0cb37 100644
> --- a/stubs/replay.c
> +++ b/stubs/replay.c
> @@ -102,3 +102,7 @@ int replay_get_instructions(void)
> void replay_account_executed_instructions(void)
> {
> }
> +
> +void replay_add_blocker(Error *reason)
> +{
> +}
This can be moved to the stubs patch.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process
2020-04-24 13:47 ` Jag Raman
@ 2020-04-28 16:29 ` Stefan Hajnoczi
2020-04-28 18:58 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-28 16:29 UTC (permalink / raw)
To: Jag Raman
Cc: Elena Ufimtseva, fam, swapnil.ingle, John G Johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, pbonzini, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 3579 bytes --]
On Fri, Apr 24, 2020 at 09:47:56AM -0400, Jag Raman wrote:
> > On Apr 24, 2020, at 9:12 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > On Wed, Apr 22, 2020 at 09:13:43PM -0700, elena.ufimtseva@oracle.com wrote:
> >> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> >> index f884bb6180..f74c7e927b 100644
> >> --- a/stubs/Makefile.objs
> >> +++ b/stubs/Makefile.objs
> >> @@ -20,6 +20,7 @@ stub-obj-y += migr-blocker.o
> >> stub-obj-y += change-state-handler.o
> >> stub-obj-y += monitor.o
> >> stub-obj-y += monitor-core.o
> >> +stub-obj-y += get-fd.o
> >> stub-obj-y += notify-event.o
> >> stub-obj-y += qtest.o
> >> stub-obj-y += replay.o
> >
> > audio.c, vl-stub.c, and xen-mapcache.c are added by this patch but not
> > added to Makefile.objs? Can they be removed?
>
> Hey Stefan,
>
> Sorry it’s not clear. but these files are referenced in Makefile.target.
Why is the Makefile.target change not in this patch?
Please structure patch series as logical changes that can be reviewed
sequentially. Not only is it hard for reviewers to understand what is
going on but it probably also breaks bisectability if patches contain
incomplete changes.
> >
> > This entire patch requires justification. Stubs exist so that common
> > code can be linked without optional features.
> >
> > For example, common code may call into kvm but that callback isn't
> > relevant when building with kvm accelerator support (e.g. say qemu-nbd).
> > That's where the stub function comes in. It fulfills the dependency
> > without dragging in the actual kvm accelerator code.
> >
> > Adding lots of stubs suggests you are building QEMU in a new way that
> > wasn't done before (this is true and expected for this patch series). I
> > would like to understand the reason for these stubs though. For
> > example, why do you need to stub audio?
>
> These stub functions are only used by the remote process, and not by
> QEMU itself.
>
> Our goal is to ensure that the remote process is building the smallest
> set of files necessary and these stub functions are necessary to meet
> that goal.
>
> For example, the remote process needs to build some of the functions
> defined in “hw/core/qdev-properties-system.c”. However, this file
> depends on audio.c (references audio_state_by_name()), which is not
> needed for the remote process. The alternative to stub functions would
> be to compile audio.c into the remote process, but that was not necessary
> in our judgement. When the project started out, we spent a lot of time
> figuring out which functions/files are necessary for the remote process, and
> we stubbed out the ones which are needed to resolve dependency during
> compilation, but not needed for functionality.
>
> audio.c is just an example of tens of other places where we needed to
> make similar judgements.
>
> Would you prefer if we moved these stub functions into a separate
> library (instead of stub-obj-y) which is only linked by the remote process?
It's too bad that none of these judgements were documented. As a
reviewer I have no idea what the justification for each individual stub
was.
Some stubs are unavoidable but they also indicate that the code is
tightly coupled where maybe it can be split up. The
qdev-properties-system.c example you mentioned sounds like something
that should be broken up into multiple files. Then stubs wouldn't be
necessary.
That said, adding stubs doesn't place a great burden on anyone and I
think they can be merged.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (36 preceding siblings ...)
2020-04-24 12:48 ` [PATCH RESEND v6 00/36] Initial support for multi-process qemu Stefan Hajnoczi
@ 2020-04-28 17:29 ` Stefan Hajnoczi
2020-04-28 17:47 ` Michael S. Tsirkin
2020-05-11 14:40 ` Stefan Hajnoczi
38 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-28 17:29 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 3510 bytes --]
On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimtseva@oracle.com wrote:
> We will post separate patchsets for the following improvements for
> the experimental Qemu multi-process:
> - Live migration;
> - Asynchronous communication channel;
> - Libvirt support;
>
> We welcome all your ideas, concerns, and questions for this patchset.
This patch series does two things:
1. It introduces the remote device infrastructure.
2. It creates the remote device program and the associated build changes
(makefiles, stubs, etc).
There are many patches and it's likely that a bunch more revisions will
be necessary before this can be merged.
I want to share an idea to reduce the scope and get patches merged more
quickly. It looks like the series can be reduced to 21 patches using
this approach.
I suggest dropping the remote device program from this patch series (and
maybe never bringing it back). Instead, use the softmmu target for the
remote device.
Why? Because the remote device program is just a QEMU that uses the
remote machine type and has no vCPUs:
$ qemu-system-x86_64 -chardev id=char0,... \
-M remote,chardev=char0 \
-device lsi53c810 \
-drive if=none,id=drive0,file=vm.img,format=raw \
-device scsi-hd,drive=drive0
This will use the remote machine type, interrupt controller, and PCI bus
that you have created.
The remote machine type should default to no vCPUs and no memory
creation (the memory comes via the mpqemu link communications channel).
At this point qemu-system-x86_64 contains a lot of code that you don't
want in the final remote device program. Let's ignore that for a
second.
Now you can submit a 21-patch series containing just the remote device
infrastructure. This will be easier to merge.
Returning to code size, the next step is to reduce the binary. QEMU has
a Kconfig-style system for optional features and dependencies. It's a
better approach than creating a separate make target because it
eliminates the duplication and mess in the makefiles.
For example, you can disable TCG and KVM so that your binary has no
ability to execute guest code. Currently ./configure disallows this but
I've tried it and it works.
You can add a new default-configs/ file that disables CONFIG_ISAPC,
CONFIG_I440FX, etc. When you compile QEMU most of hw/ will not be built
anymore. At this point you have a smaller binary that is still a
softmmu target so the makefiles are shared with the regular
qemu-system-x86_64.
There will be some code for which there is no Kconfig option yet.
Further improvements can be made by adding Kconfig options for any code
that you wish to eliminate. Instead of writing makefile changes like
you did in this patch series you would be adding Kconfig options. The
nice thing is that this work isn't specific to the remote device program
- anyone can use the new Kconfig options to reduce the size of their
QEMU. So not only is it less messy than duplicating the makefiles,
but it also benefits everyone.
The downside to doing this is that it will take a while to eliminate all
code that you don't want via Kconfig. However, your initial patch
series can be merged sooner and I think this direction is also cleaner.
I hope I've explained the idea properly :). We can continue reviewing
the current series if you prefer, but I think it would be quicker to
drop the remote device program.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-28 17:29 ` Stefan Hajnoczi
@ 2020-04-28 17:47 ` Michael S. Tsirkin
2020-04-29 9:30 ` Stefan Hajnoczi
0 siblings, 1 reply; 94+ messages in thread
From: Michael S. Tsirkin @ 2020-04-28 17:47 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, jag.raman, quintela, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
On Tue, Apr 28, 2020 at 06:29:20PM +0100, Stefan Hajnoczi wrote:
> On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimtseva@oracle.com wrote:
> > We will post separate patchsets for the following improvements for
> > the experimental Qemu multi-process:
> > - Live migration;
> > - Asynchronous communication channel;
> > - Libvirt support;
> >
> > We welcome all your ideas, concerns, and questions for this patchset.
>
> This patch series does two things:
> 1. It introduces the remote device infrastructure.
> 2. It creates the remote device program and the associated build changes
> (makefiles, stubs, etc).
>
> There are many patches and it's likely that a bunch more revisions will
> be necessary before this can be merged.
>
> I want to share an idea to reduce the scope and get patches merged more
> quickly. It looks like the series can be reduced to 21 patches using
> this approach.
>
> I suggest dropping the remote device program from this patch series (and
> maybe never bringing it back). Instead, use the softmmu target for the
> remote device.
>
> Why? Because the remote device program is just a QEMU that uses the
> remote machine type and has no vCPUs:
>
> $ qemu-system-x86_64 -chardev id=char0,... \
> -M remote,chardev=char0 \
> -device lsi53c810 \
> -drive if=none,id=drive0,file=vm.img,format=raw \
> -device scsi-hd,drive=drive0
>
> This will use the remote machine type, interrupt controller, and PCI bus
> that you have created.
>
> The remote machine type should default to no vCPUs and no memory
> creation (the memory comes via the mpqemu link communications channel).
>
> At this point qemu-system-x86_64 contains a lot of code that you don't
> want in the final remote device program. Let's ignore that for a
> second.
>
> Now you can submit a 21-patch series containing just the remote device
> infrastructure. This will be easier to merge.
>
> Returning to code size, the next step is to reduce the binary. QEMU has
> a Kconfig-style system for optional features and dependencies. It's a
> better approach than creating a separate make target because it
> eliminates the duplication and mess in the makefiles.
>
> For example, you can disable TCG and KVM so that your binary has no
> ability to execute guest code. Currently ./configure disallows this but
> I've tried it and it works.
>
> You can add a new default-configs/ file that disables CONFIG_ISAPC,
> CONFIG_I440FX, etc. When you compile QEMU most of hw/ will not be built
> anymore. At this point you have a smaller binary that is still a
> softmmu target so the makefiles are shared with the regular
> qemu-system-x86_64.
>
> There will be some code for which there is no Kconfig option yet.
> Further improvements can be made by adding Kconfig options for any code
> that you wish to eliminate. Instead of writing makefile changes like
> you did in this patch series you would be adding Kconfig options. The
> nice thing is that this work isn't specific to the remote device program
> - anyone can use the new Kconfig options to reduce the size of their
> QEMU. So not only is it less messy than duplicating the makefiles,
> but it also benefits everyone.
>
> The downside to doing this is that it will take a while to eliminate all
> code that you don't want via Kconfig. However, your initial patch
> series can be merged sooner and I think this direction is also cleaner.
>
> I hope I've explained the idea properly :). We can continue reviewing
> the current series if you prefer, but I think it would be quicker to
> drop the remote device program.
>
> Stefan
Building QEMU twices just to get the remote is however not very
attractive. So how about making remote a special target?
Either remote-softmmu/ or if impossible x86_64-remote-softmmu/
--
MST
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process
2020-04-28 16:29 ` Stefan Hajnoczi
@ 2020-04-28 18:58 ` Jag Raman
2020-04-29 9:41 ` Stefan Hajnoczi
0 siblings, 1 reply; 94+ messages in thread
From: Jag Raman @ 2020-04-28 18:58 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
> On Apr 28, 2020, at 12:29 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Fri, Apr 24, 2020 at 09:47:56AM -0400, Jag Raman wrote:
>>> On Apr 24, 2020, at 9:12 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>>> On Wed, Apr 22, 2020 at 09:13:43PM -0700, elena.ufimtseva@oracle.com wrote:
>>>> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
>>>> index f884bb6180..f74c7e927b 100644
>>>> --- a/stubs/Makefile.objs
>>>> +++ b/stubs/Makefile.objs
>>>> @@ -20,6 +20,7 @@ stub-obj-y += migr-blocker.o
>>>> stub-obj-y += change-state-handler.o
>>>> stub-obj-y += monitor.o
>>>> stub-obj-y += monitor-core.o
>>>> +stub-obj-y += get-fd.o
>>>> stub-obj-y += notify-event.o
>>>> stub-obj-y += qtest.o
>>>> stub-obj-y += replay.o
>>>
>>> audio.c, vl-stub.c, and xen-mapcache.c are added by this patch but not
>>> added to Makefile.objs? Can they be removed?
>>
>> Hey Stefan,
>>
>> Sorry it’s not clear. but these files are referenced in Makefile.target.
>
> Why is the Makefile.target change not in this patch?
>
> Please structure patch series as logical changes that can be reviewed
> sequentially. Not only is it hard for reviewers to understand what is
> going on but it probably also breaks bisectability if patches contain
> incomplete changes.
Hi Stefan,
We grouped all the stubs into a separate patch for ease of review. If you’re finding
it hard to review this way, we’ll modify to ensure that the Makefile changes go along
with the stubs.
--
Jag
>
>>>
>>> This entire patch requires justification. Stubs exist so that common
>>> code can be linked without optional features.
>>>
>>> For example, common code may call into kvm but that callback isn't
>>> relevant when building with kvm accelerator support (e.g. say qemu-nbd).
>>> That's where the stub function comes in. It fulfills the dependency
>>> without dragging in the actual kvm accelerator code.
>>>
>>> Adding lots of stubs suggests you are building QEMU in a new way that
>>> wasn't done before (this is true and expected for this patch series). I
>>> would like to understand the reason for these stubs though. For
>>> example, why do you need to stub audio?
>>
>> These stub functions are only used by the remote process, and not by
>> QEMU itself.
>>
>> Our goal is to ensure that the remote process is building the smallest
>> set of files necessary and these stub functions are necessary to meet
>> that goal.
>>
>> For example, the remote process needs to build some of the functions
>> defined in “hw/core/qdev-properties-system.c”. However, this file
>> depends on audio.c (references audio_state_by_name()), which is not
>> needed for the remote process. The alternative to stub functions would
>> be to compile audio.c into the remote process, but that was not necessary
>> in our judgement. When the project started out, we spent a lot of time
>> figuring out which functions/files are necessary for the remote process, and
>> we stubbed out the ones which are needed to resolve dependency during
>> compilation, but not needed for functionality.
>>
>> audio.c is just an example of tens of other places where we needed to
>> make similar judgements.
>>
>> Would you prefer if we moved these stub functions into a separate
>> library (instead of stub-obj-y) which is only linked by the remote process?
>
> It's too bad that none of these judgements were documented. As a
> reviewer I have no idea what the justification for each individual stub
> was.
>
> Some stubs are unavoidable but they also indicate that the code is
> tightly coupled where maybe it can be split up. The
> qdev-properties-system.c example you mentioned sounds like something
> that should be broken up into multiple files. Then stubs wouldn't be
> necessary.
>
> That said, adding stubs doesn't place a great burden on anyone and I
> think they can be merged.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-28 17:47 ` Michael S. Tsirkin
@ 2020-04-29 9:30 ` Stefan Hajnoczi
2020-04-29 9:59 ` Michael S. Tsirkin
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-29 9:30 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, jag.raman, quintela, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
[-- Attachment #1: Type: text/plain, Size: 4547 bytes --]
On Tue, Apr 28, 2020 at 01:47:24PM -0400, Michael S. Tsirkin wrote:
> On Tue, Apr 28, 2020 at 06:29:20PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Apr 22, 2020 at 09:13:35PM -0700, elena.ufimtseva@oracle.com wrote:
> > > We will post separate patchsets for the following improvements for
> > > the experimental Qemu multi-process:
> > > - Live migration;
> > > - Asynchronous communication channel;
> > > - Libvirt support;
> > >
> > > We welcome all your ideas, concerns, and questions for this patchset.
> >
> > This patch series does two things:
> > 1. It introduces the remote device infrastructure.
> > 2. It creates the remote device program and the associated build changes
> > (makefiles, stubs, etc).
> >
> > There are many patches and it's likely that a bunch more revisions will
> > be necessary before this can be merged.
> >
> > I want to share an idea to reduce the scope and get patches merged more
> > quickly. It looks like the series can be reduced to 21 patches using
> > this approach.
> >
> > I suggest dropping the remote device program from this patch series (and
> > maybe never bringing it back). Instead, use the softmmu target for the
> > remote device.
> >
> > Why? Because the remote device program is just a QEMU that uses the
> > remote machine type and has no vCPUs:
> >
> > $ qemu-system-x86_64 -chardev id=char0,... \
> > -M remote,chardev=char0 \
> > -device lsi53c810 \
> > -drive if=none,id=drive0,file=vm.img,format=raw \
> > -device scsi-hd,drive=drive0
> >
> > This will use the remote machine type, interrupt controller, and PCI bus
> > that you have created.
> >
> > The remote machine type should default to no vCPUs and no memory
> > creation (the memory comes via the mpqemu link communications channel).
> >
> > At this point qemu-system-x86_64 contains a lot of code that you don't
> > want in the final remote device program. Let's ignore that for a
> > second.
> >
> > Now you can submit a 21-patch series containing just the remote device
> > infrastructure. This will be easier to merge.
> >
> > Returning to code size, the next step is to reduce the binary. QEMU has
> > a Kconfig-style system for optional features and dependencies. It's a
> > better approach than creating a separate make target because it
> > eliminates the duplication and mess in the makefiles.
> >
> > For example, you can disable TCG and KVM so that your binary has no
> > ability to execute guest code. Currently ./configure disallows this but
> > I've tried it and it works.
> >
> > You can add a new default-configs/ file that disables CONFIG_ISAPC,
> > CONFIG_I440FX, etc. When you compile QEMU most of hw/ will not be built
> > anymore. At this point you have a smaller binary that is still a
> > softmmu target so the makefiles are shared with the regular
> > qemu-system-x86_64.
> >
> > There will be some code for which there is no Kconfig option yet.
> > Further improvements can be made by adding Kconfig options for any code
> > that you wish to eliminate. Instead of writing makefile changes like
> > you did in this patch series you would be adding Kconfig options. The
> > nice thing is that this work isn't specific to the remote device program
> > - anyone can use the new Kconfig options to reduce the size of their
> > QEMU. So not only is it less messy than duplicating the makefiles,
> > but it also benefits everyone.
> >
> > The downside to doing this is that it will take a while to eliminate all
> > code that you don't want via Kconfig. However, your initial patch
> > series can be merged sooner and I think this direction is also cleaner.
> >
> > I hope I've explained the idea properly :). We can continue reviewing
> > the current series if you prefer, but I think it would be quicker to
> > drop the remote device program.
> >
> > Stefan
>
> Building QEMU twices just to get the remote is however not very
> attractive. So how about making remote a special target?
> Either remote-softmmu/ or if impossible x86_64-remote-softmmu/
Yes, that's a good idea. It needs to be the full x86_64-remote-softmmu
because hw/ code depends on the QEMU target :(.
To summarize the big advantage of this approach (besides reducing the
patch series): the existing makefile rules for softmmu will be used to
build the remote device program. No new main() and no new per-object
file makefile rules are needed.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process
2020-04-28 18:58 ` Jag Raman
@ 2020-04-29 9:41 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-04-29 9:41 UTC (permalink / raw)
To: Jag Raman
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]
On Tue, Apr 28, 2020 at 02:58:21PM -0400, Jag Raman wrote:
> > On Apr 28, 2020, at 12:29 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > On Fri, Apr 24, 2020 at 09:47:56AM -0400, Jag Raman wrote:
> >>> On Apr 24, 2020, at 9:12 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >>> On Wed, Apr 22, 2020 at 09:13:43PM -0700, elena.ufimtseva@oracle.com wrote:
> >>>> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> >>>> index f884bb6180..f74c7e927b 100644
> >>>> --- a/stubs/Makefile.objs
> >>>> +++ b/stubs/Makefile.objs
> >>>> @@ -20,6 +20,7 @@ stub-obj-y += migr-blocker.o
> >>>> stub-obj-y += change-state-handler.o
> >>>> stub-obj-y += monitor.o
> >>>> stub-obj-y += monitor-core.o
> >>>> +stub-obj-y += get-fd.o
> >>>> stub-obj-y += notify-event.o
> >>>> stub-obj-y += qtest.o
> >>>> stub-obj-y += replay.o
> >>>
> >>> audio.c, vl-stub.c, and xen-mapcache.c are added by this patch but not
> >>> added to Makefile.objs? Can they be removed?
> >>
> >> Hey Stefan,
> >>
> >> Sorry it’s not clear. but these files are referenced in Makefile.target.
> >
> > Why is the Makefile.target change not in this patch?
> >
> > Please structure patch series as logical changes that can be reviewed
> > sequentially. Not only is it hard for reviewers to understand what is
> > going on but it probably also breaks bisectability if patches contain
> > incomplete changes.
>
> Hi Stefan,
>
> We grouped all the stubs into a separate patch for ease of review. If you’re finding
> it hard to review this way, we’ll modify to ensure that the Makefile changes go along
> with the stubs.
Grouping all the stubs into a single patch isn't a problem.
The issue is that some of the new .c files are not referenced by any
makefile rules. They aren't being compiled and may contain syntax
errors.
There is also no justification for these stubs so reviewers don't know
why exactly they are needed. I would have liked to know what required
the creation of each stub. If you don't remember the details anymore
then let's not worry about it, but sometimes there are cleaner ways of
resolving dependencies than adding stubs.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-29 9:30 ` Stefan Hajnoczi
@ 2020-04-29 9:59 ` Michael S. Tsirkin
0 siblings, 0 replies; 94+ messages in thread
From: Michael S. Tsirkin @ 2020-04-29 9:59 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, jag.raman, quintela, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
On Wed, Apr 29, 2020 at 10:30:30AM +0100, Stefan Hajnoczi wrote:
> > > I suggest dropping the remote device program from this patch series (and
> > > maybe never bringing it back). Instead, use the softmmu target for the
> > > remote device.
...
> >
> > Building QEMU twices just to get the remote is however not very
> > attractive. So how about making remote a special target?
> > Either remote-softmmu/ or if impossible x86_64-remote-softmmu/
>
> Yes, that's a good idea. It needs to be the full x86_64-remote-softmmu
> because hw/ code depends on the QEMU target :(.
BTW using QEMU as backend source also gives us goodies such as
cross-version compatibility for free.
--
MST
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
` (37 preceding siblings ...)
2020-04-28 17:29 ` Stefan Hajnoczi
@ 2020-05-11 14:40 ` Stefan Hajnoczi
2020-05-11 19:30 ` Jag Raman
38 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-11 14:40 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha, pbonzini,
rth, kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 205 bytes --]
Hi,
Have you decided whether to drop the remote device program in favor of
using a softmmu make target?
Is there anything in this series you'd like me to review before you send
the next revision?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-05-11 14:40 ` Stefan Hajnoczi
@ 2020-05-11 19:30 ` Jag Raman
2020-05-12 16:13 ` Stefan Hajnoczi
0 siblings, 1 reply; 94+ messages in thread
From: Jag Raman @ 2020-05-11 19:30 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, Swapnil Ingle, john.g.johnson, qemu-devel,
kraxel, quintela, Michael S. Tsirkin, armbru, kanth.ghatraju,
felipe, thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
stefanha, pbonzini, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
> On May 11, 2020, at 10:40 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Hi,
> Have you decided whether to drop the remote device program in favor of
> using a softmmu make target?
>
> Is there anything in this series you'd like me to review before you send
> the next revision?
Hi Stefan,
We are planning to drop the separate remote device program in the next
revision. We are planning to use QEMU’s existing event loop instead of
a separate event loop for the remote process, as well as the command
line invocation you suggested in your feedback.
We hope the following core patches look good to you, by and large:
[PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
[PATCH RESEND v6 11/36] multi-process: define mpqemu-link object
[PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints
[PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device
[PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process
[PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device
[PATCH RESEND v6 17/36] multi-process: introduce proxy object
[PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel
[PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process
[PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to the remote process
[PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints
[PATCH RESEND v6 22/36] multi-process: Synchronize remote memory
[PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq
[PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process
Thank you very much!
—
Jag
>
> Stefan
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-04-23 4:13 ` [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset elena.ufimtseva
@ 2020-05-12 8:26 ` Stefan Hajnoczi
2020-05-12 8:48 ` Daniel P. Berrangé
1 sibling, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 8:26 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Allow RAM MemoryRegion to be created from an offset in a file, instead
> of allocating at offset of 0 by default. This is needed to synchronize
> RAM between QEMU & remote process.
>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
> exec.c | 11 +++++++----
> include/exec/ram_addr.h | 2 +-
> include/qemu/mmap-alloc.h | 3 ++-
> memory.c | 2 +-
> util/mmap-alloc.c | 7 ++++---
> util/oslib-posix.c | 2 +-
> 6 files changed, 16 insertions(+), 11 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-04-23 4:13 ` [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset elena.ufimtseva
2020-05-12 8:26 ` Stefan Hajnoczi
@ 2020-05-12 8:48 ` Daniel P. Berrangé
2020-05-12 11:56 ` Jag Raman
1 sibling, 1 reply; 94+ messages in thread
From: Daniel P. Berrangé @ 2020-05-12 8:48 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha,
thanos.makatos, rth, kwolf, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Allow RAM MemoryRegion to be created from an offset in a file, instead
> of allocating at offset of 0 by default. This is needed to synchronize
> RAM between QEMU & remote process.
Can you elaborate on why remote processes require the RAM to be offset
from zero ?
NB, I'm not objecting - I'm just curious to understand more.
>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
> exec.c | 11 +++++++----
> include/exec/ram_addr.h | 2 +-
> include/qemu/mmap-alloc.h | 3 ++-
> memory.c | 2 +-
> util/mmap-alloc.c | 7 ++++---
> util/oslib-posix.c | 2 +-
> 6 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index 2874bb5088..d0ac9545f4 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1801,6 +1801,7 @@ static void *file_ram_alloc(RAMBlock *block,
> ram_addr_t memory,
> int fd,
> bool truncate,
> + off_t offset,
> Error **errp)
> {
> void *area;
> @@ -1851,7 +1852,8 @@ static void *file_ram_alloc(RAMBlock *block,
> }
>
> area = qemu_ram_mmap(fd, memory, block->mr->align,
> - block->flags & RAM_SHARED, block->flags & RAM_PMEM);
> + block->flags & RAM_SHARED, block->flags & RAM_PMEM,
> + offset);
> if (area == MAP_FAILED) {
> error_setg_errno(errp, errno,
> "unable to map backing store for guest RAM");
> @@ -2283,7 +2285,7 @@ static void ram_block_add(RAMBlock *new_block, Error **errp, bool shared)
> #ifdef CONFIG_POSIX
> RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
> uint32_t ram_flags, int fd,
> - Error **errp)
> + off_t offset, Error **errp)
> {
> RAMBlock *new_block;
> Error *local_err = NULL;
> @@ -2328,7 +2330,8 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
> new_block->used_length = size;
> new_block->max_length = size;
> new_block->flags = ram_flags;
> - new_block->host = file_ram_alloc(new_block, size, fd, !file_size, errp);
> + new_block->host = file_ram_alloc(new_block, size, fd, !file_size, offset,
> + errp);
> if (!new_block->host) {
> g_free(new_block);
> return NULL;
> @@ -2358,7 +2361,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
> return NULL;
> }
>
> - block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, errp);
> + block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, 0, errp);
> if (!block) {
> if (created) {
> unlink(mem_path);
> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> index 5e59a3d8d7..1b9f489ff0 100644
> --- a/include/exec/ram_addr.h
> +++ b/include/exec/ram_addr.h
> @@ -121,7 +121,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
> Error **errp);
> RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
> uint32_t ram_flags, int fd,
> - Error **errp);
> + off_t offset, Error **errp);
>
> RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
> MemoryRegion *mr, Error **errp);
> diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
> index e786266b92..4f579858bc 100644
> --- a/include/qemu/mmap-alloc.h
> +++ b/include/qemu/mmap-alloc.h
> @@ -25,7 +25,8 @@ void *qemu_ram_mmap(int fd,
> size_t size,
> size_t align,
> bool shared,
> - bool is_pmem);
> + bool is_pmem,
> + off_t start);
>
> void qemu_ram_munmap(int fd, void *ptr, size_t size);
>
> diff --git a/memory.c b/memory.c
> index 601b749906..f5fec476b7 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -1596,7 +1596,7 @@ void memory_region_init_ram_from_fd(MemoryRegion *mr,
> mr->destructor = memory_region_destructor_ram;
> mr->ram_block = qemu_ram_alloc_from_fd(size, mr,
> share ? RAM_SHARED : 0,
> - fd, &err);
> + fd, 0, &err);
> mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
> if (err) {
> mr->size = int128_zero();
> diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
> index 27dcccd8ec..a28f7025f0 100644
> --- a/util/mmap-alloc.c
> +++ b/util/mmap-alloc.c
> @@ -86,7 +86,8 @@ void *qemu_ram_mmap(int fd,
> size_t size,
> size_t align,
> bool shared,
> - bool is_pmem)
> + bool is_pmem,
> + off_t start)
> {
> int flags;
> int map_sync_flags = 0;
> @@ -147,7 +148,7 @@ void *qemu_ram_mmap(int fd,
> offset = QEMU_ALIGN_UP((uintptr_t)guardptr, align) - (uintptr_t)guardptr;
>
> ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE,
> - flags | map_sync_flags, fd, 0);
> + flags | map_sync_flags, fd, start);
>
> if (ptr == MAP_FAILED && map_sync_flags) {
> if (errno == ENOTSUP) {
> @@ -172,7 +173,7 @@ void *qemu_ram_mmap(int fd,
> * we will remove these flags to handle compatibility.
> */
> ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE,
> - flags, fd, 0);
> + flags, fd, start);
> }
>
> if (ptr == MAP_FAILED) {
> diff --git a/util/oslib-posix.c b/util/oslib-posix.c
> index 062236a1ab..4c6b9e90c6 100644
> --- a/util/oslib-posix.c
> +++ b/util/oslib-posix.c
> @@ -209,7 +209,7 @@ void *qemu_memalign(size_t alignment, size_t size)
> void *qemu_anon_ram_alloc(size_t size, uint64_t *alignment, bool shared)
> {
> size_t align = QEMU_VMALLOC_ALIGN;
> - void *ptr = qemu_ram_mmap(-1, size, align, shared, false);
> + void *ptr = qemu_ram_mmap(-1, size, align, shared, false, 0);
>
> if (ptr == MAP_FAILED) {
> return NULL;
> --
> 2.25.GIT
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object
2020-04-23 4:13 ` [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object elena.ufimtseva
@ 2020-05-12 8:56 ` Stefan Hajnoczi
2020-05-12 12:09 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 8:56 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 5581 bytes --]
On Wed, Apr 22, 2020 at 09:13:46PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Defines mpqemu-link object which forms the communication link between
> QEMU & emulation program.
> Adds functions to configure members of mpqemu-link object instance.
> Adds functions to send and receive messages over the communication
> channel.
> Adds GMainLoop to handle events received on the communication channel.
>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
This will change a lot when integrated into the QEMU event loop so I've
skipped a lot of the code.
QIOChannel is probably the appropriate object to use instead of directly
accessing a file descriptor.
> +/**
> + * mpqemu_cmd_t:
> + *
> + * proc_cmd_t enum type to specify the command to be executed on the remote
> + * device.
> + */
> +typedef enum {
> + INIT = 0,
> + MAX,
> +} mpqemu_cmd_t;
> +
> +/**
> + * MPQemuMsg:
> + * @cmd: The remote command
> + * @bytestream: Indicates if the data to be shared is structured (data1)
> + * or unstructured (data2)
> + * @size: Size of the data to be shared
> + * @data1: Structured data
> + * @fds: File descriptors to be shared with remote device
> + * @data2: Unstructured data
> + *
> + * MPQemuMsg Format of the message sent to the remote device from QEMU.
> + *
> + */
> +typedef struct {
> + mpqemu_cmd_t cmd;
Please use an int field on the wire because the C standard says:
Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the
values of all the members of the enumeration.
So the compiler may make this a char field (which would introduce
padding before the bytestream field) but if a new enum constant FOO =
0x100 is added then the compiler might change the size to 16-bit.
> +int mpqemu_msg_recv(MPQemuMsg *msg, MPQemuChannel *chan)
> +{
> + int rc;
> + uint8_t *data;
> + union {
> + char control[CMSG_SPACE(REMOTE_MAX_FDS * sizeof(int))];
> + struct cmsghdr align;
> + } u;
> + struct msghdr hdr;
> + struct cmsghdr *chdr;
> + size_t fdsize;
> + int sock = chan->sock;
> + QemuMutex *lock = &chan->recv_lock;
> +
> + struct iovec iov = {
> + .iov_base = (char *) msg,
> + .iov_len = MPQEMU_MSG_HDR_SIZE,
> + };
> +
> + memset(&hdr, 0, sizeof(hdr));
> + memset(&u, 0, sizeof(u));
> +
> + hdr.msg_iov = &iov;
> + hdr.msg_iovlen = 1;
> + hdr.msg_control = &u;
> + hdr.msg_controllen = sizeof(u);
> +
> + WITH_QEMU_LOCK_GUARD(lock) {
> + do {
> + rc = recvmsg(sock, &hdr, 0);
> + } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> +
> + if (rc < 0) {
Missing rc != MPQEMU_MSG_HDR_SIZE check. If this was a short read we
should not attempt to parse uninitialized bytes in msg.
This is more defensive than relying on catching bogus input values later
on and also protects against accidentally revealing uninitialized memory
contents by observing our error handling response.
> + qemu_log_mask(LOG_REMOTE_DEBUG, "%s - recvmsg rc is %d, "
> + "errno is %d, sock %d\n", __func__, rc, errno, sock);
> + return rc;
> + }
> +
> + msg->num_fds = 0;
> + for (chdr = CMSG_FIRSTHDR(&hdr); chdr != NULL;
> + chdr = CMSG_NXTHDR(&hdr, chdr)) {
> + if ((chdr->cmsg_level == SOL_SOCKET) &&
> + (chdr->cmsg_type == SCM_RIGHTS)) {
> + fdsize = chdr->cmsg_len - CMSG_LEN(0);
> + msg->num_fds = fdsize / sizeof(int);
> + if (msg->num_fds > REMOTE_MAX_FDS) {
> + qemu_log_mask(LOG_REMOTE_DEBUG,
> + "%s: Max FDs exceeded\n", __func__);
> + return -ERANGE;
> + }
> +
> + memcpy(msg->fds, CMSG_DATA(chdr), fdsize);
> + break;
> + }
> + }
> +
> + if (msg->bytestream) {
> + if (!msg->size) {
> + qemu_mutex_unlock(lock);
Duplicate unlock, we're already inside WITH_QEMU_LOCK_GUARD().
> + return -EINVAL;
> + }
> +
> + msg->data2 = calloc(1, msg->size);
What is the maximum message size? Please pick one and enforce it to
protect against huge allocations that cause us to run out of memory.
> + data = msg->data2;
> + } else {
> + data = (uint8_t *)&msg->data1;
Adding a uint8_t member to the union eliminates the need for a cast:
union {
uint64_t u64;
uint8_t u8;
} data1;
...
data = &msg->data1.u8;
> + }
> +
> + if (msg->size) {
> + do {
> + rc = read(sock, data, msg->size);
> + } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> + }
Short reads are an error. Please check that the sum of rc values is
equal to msg->size.
> + }
> + return rc;
> +}
...
> +bool mpqemu_msg_valid(MPQemuMsg *msg)
> +{
> + if (msg->cmd >= MAX) {
> + return false;
> + }
Checking msg->cmd < 0 is also useful here, especially when the field
type is changed to int.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints
2020-04-23 4:13 ` [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints elena.ufimtseva
@ 2020-05-12 10:21 ` Stefan Hajnoczi
2020-05-12 12:28 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 10:21 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 4766 bytes --]
On Wed, Apr 22, 2020 at 09:13:47PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> In some cases, for example MMIO read, QEMU has to wait for the remote to
> complete a command before proceeding. An eventfd based mechanism is
> added to synchronize QEMU & remote process.
Why are temporary eventfds used instead of sending a reply message from
the remote device program back to QEMU?
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> ---
> include/io/mpqemu-link.h | 7 +++++
> io/mpqemu-link.c | 61 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
> index af401e640c..ef95599bca 100644
> --- a/include/io/mpqemu-link.h
> +++ b/include/io/mpqemu-link.h
> @@ -124,4 +124,11 @@ void mpqemu_link_set_callback(MPQemuLinkState *s,
> void mpqemu_start_coms(MPQemuLinkState *s, MPQemuChannel* chan);
> bool mpqemu_msg_valid(MPQemuMsg *msg);
>
> +#define GET_REMOTE_WAIT eventfd(0, EFD_CLOEXEC)
> +#define PUT_REMOTE_WAIT(wait) close(wait)
Hiding this in macros makes the code harder to understand.
Why is an eventfd necessary instead of a reply message? It's simpler and
probably faster to use a reply message instead of creating and passing
temporary eventfds.
> +#define PROXY_LINK_WAIT_DONE 1
> +
> +uint64_t wait_for_remote(int efd);
> +void notify_proxy(int fd, uint64_t val);
> +
> #endif
> diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
> index 48f53a8928..cc0a7aecd4 100644
> --- a/io/mpqemu-link.c
> +++ b/io/mpqemu-link.c
> @@ -10,6 +10,7 @@
>
> #include "qemu/osdep.h"
> #include "qemu-common.h"
> +#include <poll.h>
>
> #include "qemu/module.h"
> #include "io/mpqemu-link.h"
> @@ -204,6 +205,66 @@ int mpqemu_msg_recv(MPQemuMsg *msg, MPQemuChannel *chan)
> return rc;
> }
>
> +/*
> + * wait_for_remote() Synchronizes QEMU and the remote process. The maximum
> + * wait time is 1s, after which the wait times out.
> + * The function alse returns a 64 bit return value after
> + * the wait. The function uses eventfd() to do the wait
> + * and pass the return values. eventfd() can't return a
> + * value of '0'. Therefore, all return values are offset
> + * by '1' at the sending end, and corrected at the
> + * receiving end.
> + */
> +
> +uint64_t wait_for_remote(int efd)
> +{
> + struct pollfd pfd = { .fd = efd, .events = POLLIN };
> + uint64_t val;
> + int ret;
> +
> + ret = poll(&pfd, 1, 1000);
This 1 second blocking operation is not allowed in an event loop since
it will stall any other event loop activity. If locks are held then
other threads may also be stalled.
It's likely that this will need to change as part of the QEMU event loop
integration. Caller code can be kept mostly unchanged if you use
coroutines.
> +
> + switch (ret) {
> + case 0:
> + qemu_log_mask(LOG_REMOTE_DEBUG, "Error wait_for_remote: Timed out\n");
> + /* TODO: Kick-off error recovery */
> + return UINT64_MAX;
> + case -1:
> + qemu_log_mask(LOG_REMOTE_DEBUG, "Poll error wait_for_remote: %s\n",
> + strerror(errno));
> + return UINT64_MAX;
> + default:
> + if (read(efd, &val, sizeof(val)) == -1) {
> + qemu_log_mask(LOG_REMOTE_DEBUG, "Error wait_for_remote: %s\n",
> + strerror(errno));
> + return UINT64_MAX;
> + }
> + }
> +
> + /*
> + * The remote process could write a non-zero value
> + * to the eventfd to wake QEMU up. However, the drawback of using eventfd
> + * for this purpose is that a return value of zero wouldn't wake QEMU up.
> + * Therefore, we offset the return value by one at the remote process and
> + * correct it in the QEMU end.
> + */
> + val = (val == UINT64_MAX) ? val : (val - 1);
> +
> + return val;
> +}
> +
> +void notify_proxy(int efd, uint64_t val)
> +{
> + val = (val == UINT64_MAX) ? val : (val + 1);
> + ssize_t len = -1;
> +
> + len = write(efd, &val, sizeof(val));
> + if (len == -1 || len != sizeof(val)) {
> + qemu_log_mask(LOG_REMOTE_DEBUG, "Error notify_proxy: %s\n",
> + strerror(errno));
> + }
> +}
> +
> static gboolean mpqemu_link_handler_prepare(GSource *gsrc, gint *timeout)
> {
> g_assert(timeout);
> --
> 2.25.GIT
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device
2020-04-23 4:13 ` [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device elena.ufimtseva
@ 2020-05-12 10:31 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 10:31 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 4753 bytes --]
On Wed, Apr 22, 2020 at 09:13:48PM -0700, elena.ufimtseva@oracle.com wrote:
> diff --git a/include/remote/pcihost.h b/include/remote/pcihost.h
> new file mode 100644
> index 0000000000..7aca9ccaf1
> --- /dev/null
> +++ b/include/remote/pcihost.h
> @@ -0,0 +1,45 @@
> +/*
> + * PCI Host for remote device
> + *
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#ifndef REMOTE_PCIHOST_H
> +#define REMOTE_PCIHOST_H
> +
> +#include <stddef.h>
> +#include <stdint.h>
> +
> +#include "exec/memory.h"
> +#include "hw/pci/pcie_host.h"
> +
> +#define TYPE_REMOTE_HOST_DEVICE "remote-pcihost"
> +#define REMOTE_HOST_DEVICE(obj) \
> + OBJECT_CHECK(RemPCIHost, (obj), TYPE_REMOTE_HOST_DEVICE)
> +
> +typedef struct RemPCIHost {
Hmm...this object has no state or behavior specific to remote device
emulation. Could you use an existing PCIe host instead? It's not clear
to me that a new object is needed.
> + /*< private >*/
> + PCIExpressHost parent_obj;
> + /*< public >*/
> +
> + /*
> + * Memory Controller Hub (MCH) may not be necessary for the emulation
> + * program. The two important reasons for implementing a PCI host in the
> + * emulation program are:
> + * - Provide a PCI bus for IO devices
> + * - Enable translation of guest PA to the PCI bar regions
> + *
> + * For both the above mentioned purposes, it doesn't look like we would
> + * need the MCH
> + */
> +
> + MemoryRegion *mr_pci_mem;
> + MemoryRegion *mr_sys_mem;
Unused?
> + MemoryRegion *mr_sys_io;
> +} RemPCIHost;
The name "RemotePCIHost" would be consistent with the QOM type and the
filename. It might seem trivial but when reading code that others have
written every time the naming changes you need to figure out why (just
an inconsistency or is this a different concept/abstraction?).
> +
> +#endif
> diff --git a/remote/Makefile.objs b/remote/Makefile.objs
> index a9b2256b2a..2757f5a265 100644
> --- a/remote/Makefile.objs
> +++ b/remote/Makefile.objs
> @@ -1 +1,2 @@
> remote-pci-obj-$(CONFIG_MPQEMU) += remote-main.o
> +remote-pci-obj-$(CONFIG_MPQEMU) += pcihost.o
> diff --git a/remote/pcihost.c b/remote/pcihost.c
> new file mode 100644
> index 0000000000..dbe081903e
> --- /dev/null
> +++ b/remote/pcihost.c
> @@ -0,0 +1,64 @@
> +/*
> + * Remote PCI host device
> + *
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include <sys/types.h>
> +#include <unistd.h>
"qemu/osdep.h" already includes these headers.
> +#include "qemu/osdep.h"
> +#include "hw/pci/pci.h"
> +#include "hw/pci/pci_host.h"
> +#include "hw/pci/pcie_host.h"
> +#include "hw/qdev-properties.h"
> +#include "remote/pcihost.h"
> +#include "exec/memory.h"
> +
> +static const char *remote_host_root_bus_path(PCIHostState *host_bridge,
> + PCIBus *rootbus)
> +{
> + return "0000:00";
> +}
> +
> +static void remote_host_realize(DeviceState *dev, Error **errp)
> +{
> + char *busname = g_strdup_printf("remote-pci-%ld", (unsigned long)getpid());
> + PCIHostState *pci = PCI_HOST_BRIDGE(dev);
> + RemPCIHost *s = REMOTE_HOST_DEVICE(dev);
> +
> + pci->bus = pci_root_bus_new(DEVICE(s), busname,
> + s->mr_pci_mem, s->mr_sys_io,
> + 0, TYPE_PCIE_BUS);
> +}
> +
> +static void remote_host_class_init(ObjectClass *klass, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(klass);
> +
> + hc->root_bus_path = remote_host_root_bus_path;
> + dc->realize = remote_host_realize;
> +
> + dc->user_creatable = false;
> + set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
> + dc->fw_name = "pci";
> +}
> +
> +static const TypeInfo remote_host_info = {
> + .name = TYPE_REMOTE_HOST_DEVICE,
> + .parent = TYPE_PCIE_HOST_BRIDGE,
> + .instance_size = sizeof(RemPCIHost),
> + .class_init = remote_host_class_init,
> +};
> +
> +static void remote_machine_register(void)
> +{
> + type_register_static(&remote_host_info);
> +}
> +
> +type_init(remote_machine_register)
The naming in this file is inconsistent:
remote_host_root_bus_path -> remote_pcihost_root_bus_path
remote_machine_register -> remote_pcihost_register
I haven't listed all instances.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process
2020-04-23 4:13 ` [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process elena.ufimtseva
@ 2020-05-12 10:43 ` Stefan Hajnoczi
2020-05-12 12:12 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 10:43 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]
On Wed, Apr 22, 2020 at 09:13:49PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> remote-machine object sets up various subsystems of the remote device
> process. Instantiate PCI host bridge object and initialize RAM, IO &
> PCI memory regions.
>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> ---
> MAINTAINERS | 2 +
> Makefile.objs | 1 +
> exec.c | 3 +-
> include/exec/address-spaces.h | 2 +
> include/remote/machine.h | 30 +++++++++++++
> remote/Makefile.objs | 2 +
> remote/machine.c | 84 +++++++++++++++++++++++++++++++++++
> remote/remote-main.c | 7 +++
Now that the separate remote emulation program is going away I think it
makes sense to move the PCIe host and machine type into hw/:
hw/pci-host/remote.c <-- PCIe host
hw/i386/remote.c <-- machine type (could be moved again later if
other architectures are supported)
> diff --git a/exec.c b/exec.c
> index d0ac9545f4..5b1e414099 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -161,7 +161,6 @@ typedef struct subpage_t {
> #define PHYS_SECTION_UNASSIGNED 0
>
> static void io_mem_init(void);
> -static void memory_map_init(void);
The memory_map_init() change is unnecessary once a softmmu target is
used since it will be called from cpu_exec_init_all().
> +static void remote_machine_init(Object *obj)
> +{
> + RemMachineState *s = REMOTE_MACHINE(obj);
> + RemPCIHost *rem_host;
> + MemoryRegion *system_memory, *system_io, *pci_memory;
> +
> + Error *error_abort = NULL;
> +
> + object_property_add_child(object_get_root(), "machine", obj, &error_abort);
> + if (error_abort) {
error_abort aborts the program so handling it is not necessary.
> + error_report_err(error_abort);
> + }
> +
> + memory_map_init();
> +
> + system_memory = get_system_memory();
> + system_io = get_system_io();
> +
> + pci_memory = g_new(MemoryRegion, 1);
> + memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
> +
> + rem_host = REMOTE_HOST_DEVICE(qdev_create(NULL, TYPE_REMOTE_HOST_DEVICE));
> +
> + rem_host->mr_pci_mem = pci_memory;
> + rem_host->mr_sys_mem = system_memory;
> + rem_host->mr_sys_io = system_io;
> +
> + s->host = rem_host;
> +
> + object_property_add_child(OBJECT(s), "remote-device", OBJECT(rem_host),
> + &error_abort);
> + if (error_abort) {
error_abort aborts the program so handling it is not necessary.
> + error_report_err(error_abort);
> + return;
> + }
> +
> + qemu_mutex_lock_iothread();
This will be executed with the iothread lock held. There is no need to
acquire it.
> + memory_region_add_subregion_overlap(system_memory, 0x0, pci_memory, -1);
> + qemu_mutex_unlock_iothread();
> +
> + qdev_init_nofail(DEVICE(rem_host));
> +}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-05-12 8:48 ` Daniel P. Berrangé
@ 2020-05-12 11:56 ` Jag Raman
2020-05-13 8:40 ` Stefan Hajnoczi
0 siblings, 1 reply; 94+ messages in thread
From: Jag Raman @ 2020-05-12 11:56 UTC (permalink / raw)
To: "Daniel P. Berrangé"
Cc: Elena Ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, stefanha, pbonzini,
rth, kwolf, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
> On May 12, 2020, at 4:48 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
>> From: Jagannathan Raman <jag.raman@oracle.com>
>>
>> Allow RAM MemoryRegion to be created from an offset in a file, instead
>> of allocating at offset of 0 by default. This is needed to synchronize
>> RAM between QEMU & remote process.
>
> Can you elaborate on why remote processes require the RAM to be offset
> from zero ?
Hi Daniel,
As it turns out, the RAM is scattered across the physical address space
(system_memory) of QEMU. Therefore, the system memory is composed
of multiple sections of RAM, and some sections start at a non-zero RAM
offset.
As a result, the remote process needs the ability to map these RAM
sections into system_memory.
Thank you!
--
Jag
>
> NB, I'm not objecting - I'm just curious to understand more.
>
>>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>> ---
>> exec.c | 11 +++++++----
>> include/exec/ram_addr.h | 2 +-
>> include/qemu/mmap-alloc.h | 3 ++-
>> memory.c | 2 +-
>> util/mmap-alloc.c | 7 ++++---
>> util/oslib-posix.c | 2 +-
>> 6 files changed, 16 insertions(+), 11 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 2874bb5088..d0ac9545f4 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -1801,6 +1801,7 @@ static void *file_ram_alloc(RAMBlock *block,
>> ram_addr_t memory,
>> int fd,
>> bool truncate,
>> + off_t offset,
>> Error **errp)
>> {
>> void *area;
>> @@ -1851,7 +1852,8 @@ static void *file_ram_alloc(RAMBlock *block,
>> }
>>
>> area = qemu_ram_mmap(fd, memory, block->mr->align,
>> - block->flags & RAM_SHARED, block->flags & RAM_PMEM);
>> + block->flags & RAM_SHARED, block->flags & RAM_PMEM,
>> + offset);
>> if (area == MAP_FAILED) {
>> error_setg_errno(errp, errno,
>> "unable to map backing store for guest RAM");
>> @@ -2283,7 +2285,7 @@ static void ram_block_add(RAMBlock *new_block, Error **errp, bool shared)
>> #ifdef CONFIG_POSIX
>> RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
>> uint32_t ram_flags, int fd,
>> - Error **errp)
>> + off_t offset, Error **errp)
>> {
>> RAMBlock *new_block;
>> Error *local_err = NULL;
>> @@ -2328,7 +2330,8 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
>> new_block->used_length = size;
>> new_block->max_length = size;
>> new_block->flags = ram_flags;
>> - new_block->host = file_ram_alloc(new_block, size, fd, !file_size, errp);
>> + new_block->host = file_ram_alloc(new_block, size, fd, !file_size, offset,
>> + errp);
>> if (!new_block->host) {
>> g_free(new_block);
>> return NULL;
>> @@ -2358,7 +2361,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
>> return NULL;
>> }
>>
>> - block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, errp);
>> + block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, 0, errp);
>> if (!block) {
>> if (created) {
>> unlink(mem_path);
>> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
>> index 5e59a3d8d7..1b9f489ff0 100644
>> --- a/include/exec/ram_addr.h
>> +++ b/include/exec/ram_addr.h
>> @@ -121,7 +121,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
>> Error **errp);
>> RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
>> uint32_t ram_flags, int fd,
>> - Error **errp);
>> + off_t offset, Error **errp);
>>
>> RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
>> MemoryRegion *mr, Error **errp);
>> diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
>> index e786266b92..4f579858bc 100644
>> --- a/include/qemu/mmap-alloc.h
>> +++ b/include/qemu/mmap-alloc.h
>> @@ -25,7 +25,8 @@ void *qemu_ram_mmap(int fd,
>> size_t size,
>> size_t align,
>> bool shared,
>> - bool is_pmem);
>> + bool is_pmem,
>> + off_t start);
>>
>> void qemu_ram_munmap(int fd, void *ptr, size_t size);
>>
>> diff --git a/memory.c b/memory.c
>> index 601b749906..f5fec476b7 100644
>> --- a/memory.c
>> +++ b/memory.c
>> @@ -1596,7 +1596,7 @@ void memory_region_init_ram_from_fd(MemoryRegion *mr,
>> mr->destructor = memory_region_destructor_ram;
>> mr->ram_block = qemu_ram_alloc_from_fd(size, mr,
>> share ? RAM_SHARED : 0,
>> - fd, &err);
>> + fd, 0, &err);
>> mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
>> if (err) {
>> mr->size = int128_zero();
>> diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
>> index 27dcccd8ec..a28f7025f0 100644
>> --- a/util/mmap-alloc.c
>> +++ b/util/mmap-alloc.c
>> @@ -86,7 +86,8 @@ void *qemu_ram_mmap(int fd,
>> size_t size,
>> size_t align,
>> bool shared,
>> - bool is_pmem)
>> + bool is_pmem,
>> + off_t start)
>> {
>> int flags;
>> int map_sync_flags = 0;
>> @@ -147,7 +148,7 @@ void *qemu_ram_mmap(int fd,
>> offset = QEMU_ALIGN_UP((uintptr_t)guardptr, align) - (uintptr_t)guardptr;
>>
>> ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE,
>> - flags | map_sync_flags, fd, 0);
>> + flags | map_sync_flags, fd, start);
>>
>> if (ptr == MAP_FAILED && map_sync_flags) {
>> if (errno == ENOTSUP) {
>> @@ -172,7 +173,7 @@ void *qemu_ram_mmap(int fd,
>> * we will remove these flags to handle compatibility.
>> */
>> ptr = mmap(guardptr + offset, size, PROT_READ | PROT_WRITE,
>> - flags, fd, 0);
>> + flags, fd, start);
>> }
>>
>> if (ptr == MAP_FAILED) {
>> diff --git a/util/oslib-posix.c b/util/oslib-posix.c
>> index 062236a1ab..4c6b9e90c6 100644
>> --- a/util/oslib-posix.c
>> +++ b/util/oslib-posix.c
>> @@ -209,7 +209,7 @@ void *qemu_memalign(size_t alignment, size_t size)
>> void *qemu_anon_ram_alloc(size_t size, uint64_t *alignment, bool shared)
>> {
>> size_t align = QEMU_VMALLOC_ALIGN;
>> - void *ptr = qemu_ram_mmap(-1, size, align, shared, false);
>> + void *ptr = qemu_ram_mmap(-1, size, align, shared, false, 0);
>>
>> if (ptr == MAP_FAILED) {
>> return NULL;
>> --
>> 2.25.GIT
>>
>
> Regards,
> Daniel
> --
> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o- https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
>
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object
2020-05-12 8:56 ` Stefan Hajnoczi
@ 2020-05-12 12:09 ` Jag Raman
0 siblings, 0 replies; 94+ messages in thread
From: Jag Raman @ 2020-05-12 12:09 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, swapnil.ingle, John G Johnson, qemu-devel,
kraxel, quintela, Michael S. Tsirkin, armbru, kanth.ghatraju,
felipe, thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
thanos.makatos, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, pbonzini
> On May 12, 2020, at 4:56 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Wed, Apr 22, 2020 at 09:13:46PM -0700, elena.ufimtseva@oracle.com wrote:
>> From: Jagannathan Raman <jag.raman@oracle.com>
>>
>> Defines mpqemu-link object which forms the communication link between
>> QEMU & emulation program.
>> Adds functions to configure members of mpqemu-link object instance.
>> Adds functions to send and receive messages over the communication
>> channel.
>> Adds GMainLoop to handle events received on the communication channel.
>>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>
> This will change a lot when integrated into the QEMU event loop so I've
> skipped a lot of the code.
>
> QIOChannel is probably the appropriate object to use instead of directly
> accessing a file descriptor.
OK, got it. Thanks!
>
>> +/**
>> + * mpqemu_cmd_t:
>> + *
>> + * proc_cmd_t enum type to specify the command to be executed on the remote
>> + * device.
>> + */
>> +typedef enum {
>> + INIT = 0,
>> + MAX,
>> +} mpqemu_cmd_t;
>> +
>> +/**
>> + * MPQemuMsg:
>> + * @cmd: The remote command
>> + * @bytestream: Indicates if the data to be shared is structured (data1)
>> + * or unstructured (data2)
>> + * @size: Size of the data to be shared
>> + * @data1: Structured data
>> + * @fds: File descriptors to be shared with remote device
>> + * @data2: Unstructured data
>> + *
>> + * MPQemuMsg Format of the message sent to the remote device from QEMU.
>> + *
>> + */
>> +typedef struct {
>> + mpqemu_cmd_t cmd;
>
> Please use an int field on the wire because the C standard says:
>
> Each enumerated type shall be compatible with char, a signed integer
> type, or an unsigned integer type. The choice of type is
> implementation-defined, but shall be capable of representing the
> values of all the members of the enumeration.
>
> So the compiler may make this a char field (which would introduce
> padding before the bytestream field) but if a new enum constant FOO =
> 0x100 is added then the compiler might change the size to 16-bit.
>
>> +int mpqemu_msg_recv(MPQemuMsg *msg, MPQemuChannel *chan)
>> +{
>> + int rc;
>> + uint8_t *data;
>> + union {
>> + char control[CMSG_SPACE(REMOTE_MAX_FDS * sizeof(int))];
>> + struct cmsghdr align;
>> + } u;
>> + struct msghdr hdr;
>> + struct cmsghdr *chdr;
>> + size_t fdsize;
>> + int sock = chan->sock;
>> + QemuMutex *lock = &chan->recv_lock;
>> +
>> + struct iovec iov = {
>> + .iov_base = (char *) msg,
>> + .iov_len = MPQEMU_MSG_HDR_SIZE,
>> + };
>> +
>> + memset(&hdr, 0, sizeof(hdr));
>> + memset(&u, 0, sizeof(u));
>> +
>> + hdr.msg_iov = &iov;
>> + hdr.msg_iovlen = 1;
>> + hdr.msg_control = &u;
>> + hdr.msg_controllen = sizeof(u);
>> +
>> + WITH_QEMU_LOCK_GUARD(lock) {
>> + do {
>> + rc = recvmsg(sock, &hdr, 0);
>> + } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
>> +
>> + if (rc < 0) {
>
> Missing rc != MPQEMU_MSG_HDR_SIZE check. If this was a short read we
> should not attempt to parse uninitialized bytes in msg.
>
> This is more defensive than relying on catching bogus input values later
> on and also protects against accidentally revealing uninitialized memory
> contents by observing our error handling response.
>
>> + qemu_log_mask(LOG_REMOTE_DEBUG, "%s - recvmsg rc is %d, "
>> + "errno is %d, sock %d\n", __func__, rc, errno, sock);
>> + return rc;
>> + }
>> +
>> + msg->num_fds = 0;
>> + for (chdr = CMSG_FIRSTHDR(&hdr); chdr != NULL;
>> + chdr = CMSG_NXTHDR(&hdr, chdr)) {
>> + if ((chdr->cmsg_level == SOL_SOCKET) &&
>> + (chdr->cmsg_type == SCM_RIGHTS)) {
>> + fdsize = chdr->cmsg_len - CMSG_LEN(0);
>> + msg->num_fds = fdsize / sizeof(int);
>> + if (msg->num_fds > REMOTE_MAX_FDS) {
>> + qemu_log_mask(LOG_REMOTE_DEBUG,
>> + "%s: Max FDs exceeded\n", __func__);
>> + return -ERANGE;
>> + }
>> +
>> + memcpy(msg->fds, CMSG_DATA(chdr), fdsize);
>> + break;
>> + }
>> + }
>> +
>> + if (msg->bytestream) {
>> + if (!msg->size) {
>> + qemu_mutex_unlock(lock);
>
> Duplicate unlock, we're already inside WITH_QEMU_LOCK_GUARD().
>
>> + return -EINVAL;
>> + }
>> +
>> + msg->data2 = calloc(1, msg->size);
>
> What is the maximum message size? Please pick one and enforce it to
> protect against huge allocations that cause us to run out of memory.
>
>> + data = msg->data2;
>> + } else {
>> + data = (uint8_t *)&msg->data1;
>
> Adding a uint8_t member to the union eliminates the need for a cast:
>
> union {
> uint64_t u64;
> uint8_t u8;
> } data1;
>
> ...
>
> data = &msg->data1.u8;
>
>> + }
>> +
>> + if (msg->size) {
>> + do {
>> + rc = read(sock, data, msg->size);
>> + } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
>> + }
>
> Short reads are an error. Please check that the sum of rc values is
> equal to msg->size.
>
>> + }
>> + return rc;
>> +}
> ...
>> +bool mpqemu_msg_valid(MPQemuMsg *msg)
>> +{
>> + if (msg->cmd >= MAX) {
>> + return false;
>> + }
>
> Checking msg->cmd < 0 is also useful here, especially when the field
> type is changed to int.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device
2020-04-23 4:13 ` [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device elena.ufimtseva
@ 2020-05-12 12:11 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 12:11 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
On Wed, Apr 22, 2020 at 09:13:50PM -0700, elena.ufimtseva@oracle.com wrote:
> diff --git a/exec.c b/exec.c
> index 5b1e414099..1e02e00f00 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2371,6 +2371,23 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
>
> return block;
> }
> +
> +void qemu_ram_init_from_fd(MemoryRegion *mr, int fd, uint64_t size,
This looks like a memory_region_init_*() function, not a qemu_ram_*()
function. Why is it being added to exec.c instead of memory.c?
> + ram_addr_t offset, Error **errp)
qemu_ram_alloc_from_fd()'s offset argument has the off_t type. Why is
ram_addr_t used here?
> +typedef struct {
> + hwaddr gpas[REMOTE_MAX_FDS];
> + uint64_t sizes[REMOTE_MAX_FDS];
> + ram_addr_t offsets[REMOTE_MAX_FDS];
Should this be off_t because it's the file offset, not a RAMBlock
address?
> +} sync_sysmem_msg_t;
QEMU coding style would name this struct SyncSysMemMsg.
> +void remote_sysmem_reconfig(MPQemuMsg *msg, Error **errp)
> +{
> + sync_sysmem_msg_t *sysmem_info = &msg->data1.sync_sysmem;
> + MemoryRegion *sysmem, *subregion, *next;
> + Error *local_err = NULL;
> + int region;
> +
> + sysmem = get_system_memory();
> +
> + qemu_mutex_lock_iothread();
> +
> + memory_region_transaction_begin();
> +
> + QTAILQ_FOREACH_SAFE(subregion, &sysmem->subregions, subregions_link, next) {
> + if (subregion->ram) {
> + memory_region_del_subregion(sysmem, subregion);
> + qemu_ram_free(subregion->ram_block);
subregion is leaked. qemu_ram_free() shouldn't be called directly. It's
normally called from the MemoryRegion->destructor function but that
wasn't set up by qemu_ram_init_from_fd().
Please check how MemoryRegion lifecycles should work, update
qemu_ram_init_from_fd(), and update this function to avoid leaks.
> + }
> + }
> +
> + for (region = 0; region < msg->num_fds; region++) {
> + subregion = g_new(MemoryRegion, 1);
> + qemu_ram_init_from_fd(subregion, msg->fds[region],
> + sysmem_info->sizes[region],
> + sysmem_info->offsets[region], &local_err);
Where are is msg->fds[region] closed?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process
2020-05-12 10:43 ` Stefan Hajnoczi
@ 2020-05-12 12:12 ` Jag Raman
0 siblings, 0 replies; 94+ messages in thread
From: Jag Raman @ 2020-05-12 12:12 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, swapnil.ingle, John G Johnson, qemu-devel,
kraxel, quintela, Michael S. Tsirkin, armbru, kanth.ghatraju,
felipe, thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
pbonzini, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
> On May 12, 2020, at 6:43 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Wed, Apr 22, 2020 at 09:13:49PM -0700, elena.ufimtseva@oracle.com wrote:
>> From: Jagannathan Raman <jag.raman@oracle.com>
>>
>> remote-machine object sets up various subsystems of the remote device
>> process. Instantiate PCI host bridge object and initialize RAM, IO &
>> PCI memory regions.
>>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>> ---
>> MAINTAINERS | 2 +
>> Makefile.objs | 1 +
>> exec.c | 3 +-
>> include/exec/address-spaces.h | 2 +
>> include/remote/machine.h | 30 +++++++++++++
>> remote/Makefile.objs | 2 +
>> remote/machine.c | 84 +++++++++++++++++++++++++++++++++++
>> remote/remote-main.c | 7 +++
>
> Now that the separate remote emulation program is going away I think it
> makes sense to move the PCIe host and machine type into hw/:
>
> hw/pci-host/remote.c <-- PCIe host
> hw/i386/remote.c <-- machine type (could be moved again later if
> other architectures are supported)
OK, got it.
>
>> diff --git a/exec.c b/exec.c
>> index d0ac9545f4..5b1e414099 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -161,7 +161,6 @@ typedef struct subpage_t {
>> #define PHYS_SECTION_UNASSIGNED 0
>>
>> static void io_mem_init(void);
>> -static void memory_map_init(void);
>
> The memory_map_init() change is unnecessary once a softmmu target is
> used since it will be called from cpu_exec_init_all().
OK.
>
>> +static void remote_machine_init(Object *obj)
>> +{
>> + RemMachineState *s = REMOTE_MACHINE(obj);
>> + RemPCIHost *rem_host;
>> + MemoryRegion *system_memory, *system_io, *pci_memory;
>> +
>> + Error *error_abort = NULL;
>> +
>> + object_property_add_child(object_get_root(), "machine", obj, &error_abort);
>> + if (error_abort) {
>
> error_abort aborts the program so handling it is not necessary.
OK, thanks!
>
>> + error_report_err(error_abort);
>> + }
>> +
>> + memory_map_init();
>> +
>> + system_memory = get_system_memory();
>> + system_io = get_system_io();
>> +
>> + pci_memory = g_new(MemoryRegion, 1);
>> + memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
>> +
>> + rem_host = REMOTE_HOST_DEVICE(qdev_create(NULL, TYPE_REMOTE_HOST_DEVICE));
>> +
>> + rem_host->mr_pci_mem = pci_memory;
>> + rem_host->mr_sys_mem = system_memory;
>> + rem_host->mr_sys_io = system_io;
>> +
>> + s->host = rem_host;
>> +
>> + object_property_add_child(OBJECT(s), "remote-device", OBJECT(rem_host),
>> + &error_abort);
>> + if (error_abort) {
>
> error_abort aborts the program so handling it is not necessary.
>
>> + error_report_err(error_abort);
>> + return;
>> + }
>> +
>> + qemu_mutex_lock_iothread();
>
> This will be executed with the iothread lock held. There is no need to
> acquire it.
Yes, this wouldn’t be necessary from QEMU’s main loop.
Thanks!
--
Jag
>
>> + memory_region_add_subregion_overlap(system_memory, 0x0, pci_memory, -1);
>> + qemu_mutex_unlock_iothread();
>> +
>> + qdev_init_nofail(DEVICE(rem_host));
>> +}
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 17/36] multi-process: introduce proxy object
2020-04-23 4:13 ` [PATCH RESEND v6 17/36] multi-process: introduce proxy object elena.ufimtseva
@ 2020-05-12 12:23 ` Stefan Hajnoczi
2020-05-12 12:35 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 12:23 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]
On Wed, Apr 22, 2020 at 09:13:52PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>
> Defines a PCI Device proxy object as a parent of TYPE_PCI_DEVICE.
s/parent/child/
>
> PCI Proxy Object registers as a PCI device with QEMU and forwards all
> PCI accesses to the remote process using the communication channel.
Please include that functionality in this patch. The code below just
sets up a skeleton PCI device. There is no code that forwards accesses
to the remote process.
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> ---
> MAINTAINERS | 3 ++
> hw/Makefile.objs | 2 ++
> hw/proxy/Makefile.objs | 1 +
> hw/proxy/qemu-proxy.c | 56 +++++++++++++++++++++++++++++++++++
> include/hw/proxy/qemu-proxy.h | 46 ++++++++++++++++++++++++++++
> include/io/mpqemu-link.h | 1 +
> 6 files changed, 109 insertions(+)
> create mode 100644 hw/proxy/Makefile.objs
> create mode 100644 hw/proxy/qemu-proxy.c
> create mode 100644 include/hw/proxy/qemu-proxy.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96f8d7ff19..3da3dcd311 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2866,6 +2866,9 @@ F: include/remote/machine.h
> F: remote/machine.c
> F: include/remote/memory.h
> F: remote/memory.c
> +F: hw/proxy/Makefile.objs
> +F: hw/proxy/qemu-proxy.c
> +F: include/hw/proxy/qemu-proxy.h
It's a generic PCI device. hw/pci/proxy.c would be a good location for
it.
By the way an alternative to the "proxy"/"remote" terminology is
RemotePCIClient/RemotePCIServer. That makes it more obvious that "proxy"
is related the "remote" feature. Feel free to keep the existing
terminology, I just wanted to suggest another possibility.
>
> Build and test automation
> -------------------------
> diff --git a/hw/Makefile.objs b/hw/Makefile.objs
> index af9235b6f2..7b489b12a5 100644
> --- a/hw/Makefile.objs
> +++ b/hw/Makefile.objs
> @@ -45,6 +45,8 @@ endif
> common-obj-y += $(devices-dirs-y)
> obj-y += $(devices-dirs-y)
>
> +common-obj-$(CONFIG_MPQEMU) += proxy/
> +
> remote-pci-obj-$(CONFIG_MPQEMU) += core/
> remote-pci-obj-$(CONFIG_MPQEMU) += block/
> remote-pci-obj-$(CONFIG_MPQEMU) += pci/
> diff --git a/hw/proxy/Makefile.objs b/hw/proxy/Makefile.objs
> new file mode 100644
> index 0000000000..eb81624cf8
> --- /dev/null
> +++ b/hw/proxy/Makefile.objs
> @@ -0,0 +1 @@
> +common-obj-$(CONFIG_MPQEMU) += qemu-proxy.o
> diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
> new file mode 100644
> index 0000000000..bf6c4117ef
> --- /dev/null
> +++ b/hw/proxy/qemu-proxy.c
> @@ -0,0 +1,56 @@
> +/*
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +
> +#include "qapi/error.h"
> +#include "io/mpqemu-link.h"
> +#include "hw/proxy/qemu-proxy.h"
> +#include "hw/pci/pci.h"
> +
> +static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
> +{
> + PCIProxyDev *dev = PCI_PROXY_DEV(device);
> + PCIProxyDevClass *k = PCI_PROXY_DEV_GET_CLASS(dev);
> + Error *local_err = NULL;
> +
> + if (k->realize) {
Will anything inherit from this class? I thought this is the remote PCI
client that can acts as a stand-in for all remote PCI devices, so it's
not clear why it's acting as a base class here.
> diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
> index d46cb81058..73cc59b874 100644
> --- a/include/io/mpqemu-link.h
> +++ b/include/io/mpqemu-link.h
> @@ -14,6 +14,7 @@
> #include "qemu/osdep.h"
> #include "qemu-common.h"
>
> +#include "sys/eventfd.h"
Why? Nothing in this patch uses this header.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints
2020-05-12 10:21 ` Stefan Hajnoczi
@ 2020-05-12 12:28 ` Jag Raman
2020-05-13 8:43 ` Stefan Hajnoczi
0 siblings, 1 reply; 94+ messages in thread
From: Jag Raman @ 2020-05-12 12:28 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
kraxel, quintela, Michael S. Tsirkin, armbru, kanth.ghatraju,
felipe, thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
pbonzini, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
> On May 12, 2020, at 6:21 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Wed, Apr 22, 2020 at 09:13:47PM -0700, elena.ufimtseva@oracle.com wrote:
>> From: Jagannathan Raman <jag.raman@oracle.com>
>>
>> In some cases, for example MMIO read, QEMU has to wait for the remote to
>> complete a command before proceeding. An eventfd based mechanism is
>> added to synchronize QEMU & remote process.
>
> Why are temporary eventfds used instead of sending a reply message from
> the remote device program back to QEMU?
Originally, we were envisioning a scenario where the remote process would
interrupt QEMU with a message. We used separate eventfds to distinguish
the two.
>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>> ---
>> include/io/mpqemu-link.h | 7 +++++
>> io/mpqemu-link.c | 61 ++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 68 insertions(+)
>>
>> diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
>> index af401e640c..ef95599bca 100644
>> --- a/include/io/mpqemu-link.h
>> +++ b/include/io/mpqemu-link.h
>> @@ -124,4 +124,11 @@ void mpqemu_link_set_callback(MPQemuLinkState *s,
>> void mpqemu_start_coms(MPQemuLinkState *s, MPQemuChannel* chan);
>> bool mpqemu_msg_valid(MPQemuMsg *msg);
>>
>> +#define GET_REMOTE_WAIT eventfd(0, EFD_CLOEXEC)
>> +#define PUT_REMOTE_WAIT(wait) close(wait)
>
> Hiding this in macros makes the code harder to understand.
>
> Why is an eventfd necessary instead of a reply message? It's simpler and
> probably faster to use a reply message instead of creating and passing
> temporary eventfds.
OK, got it.
>
>> +#define PROXY_LINK_WAIT_DONE 1
>> +
>> +uint64_t wait_for_remote(int efd);
>> +void notify_proxy(int fd, uint64_t val);
>> +
>> #endif
>> diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
>> index 48f53a8928..cc0a7aecd4 100644
>> --- a/io/mpqemu-link.c
>> +++ b/io/mpqemu-link.c
>> @@ -10,6 +10,7 @@
>>
>> #include "qemu/osdep.h"
>> #include "qemu-common.h"
>> +#include <poll.h>
>>
>> #include "qemu/module.h"
>> #include "io/mpqemu-link.h"
>> @@ -204,6 +205,66 @@ int mpqemu_msg_recv(MPQemuMsg *msg, MPQemuChannel *chan)
>> return rc;
>> }
>>
>> +/*
>> + * wait_for_remote() Synchronizes QEMU and the remote process. The maximum
>> + * wait time is 1s, after which the wait times out.
>> + * The function alse returns a 64 bit return value after
>> + * the wait. The function uses eventfd() to do the wait
>> + * and pass the return values. eventfd() can't return a
>> + * value of '0'. Therefore, all return values are offset
>> + * by '1' at the sending end, and corrected at the
>> + * receiving end.
>> + */
>> +
>> +uint64_t wait_for_remote(int efd)
>> +{
>> + struct pollfd pfd = { .fd = efd, .events = POLLIN };
>> + uint64_t val;
>> + int ret;
>> +
>> + ret = poll(&pfd, 1, 1000);
>
> This 1 second blocking operation is not allowed in an event loop since
> it will stall any other event loop activity. If locks are held then
> other threads may also be stalled.
>
> It's likely that this will need to change as part of the QEMU event loop
> integration. Caller code can be kept mostly unchanged if you use
> coroutines.
In case the remote process has hung or terminated, the 1 second timeout
ensures that the IO operation does not block for too long.
--
Jag
>
>> +
>> + switch (ret) {
>> + case 0:
>> + qemu_log_mask(LOG_REMOTE_DEBUG, "Error wait_for_remote: Timed out\n");
>> + /* TODO: Kick-off error recovery */
>> + return UINT64_MAX;
>> + case -1:
>> + qemu_log_mask(LOG_REMOTE_DEBUG, "Poll error wait_for_remote: %s\n",
>> + strerror(errno));
>> + return UINT64_MAX;
>> + default:
>> + if (read(efd, &val, sizeof(val)) == -1) {
>> + qemu_log_mask(LOG_REMOTE_DEBUG, "Error wait_for_remote: %s\n",
>> + strerror(errno));
>> + return UINT64_MAX;
>> + }
>> + }
>> +
>> + /*
>> + * The remote process could write a non-zero value
>> + * to the eventfd to wake QEMU up. However, the drawback of using eventfd
>> + * for this purpose is that a return value of zero wouldn't wake QEMU up.
>> + * Therefore, we offset the return value by one at the remote process and
>> + * correct it in the QEMU end.
>> + */
>> + val = (val == UINT64_MAX) ? val : (val - 1);
>> +
>> + return val;
>> +}
>> +
>> +void notify_proxy(int efd, uint64_t val)
>> +{
>> + val = (val == UINT64_MAX) ? val : (val + 1);
>> + ssize_t len = -1;
>> +
>> + len = write(efd, &val, sizeof(val));
>> + if (len == -1 || len != sizeof(val)) {
>> + qemu_log_mask(LOG_REMOTE_DEBUG, "Error notify_proxy: %s\n",
>> + strerror(errno));
>> + }
>> +}
>> +
>> static gboolean mpqemu_link_handler_prepare(GSource *gsrc, gint *timeout)
>> {
>> g_assert(timeout);
>> --
>> 2.25.GIT
>>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel
2020-04-23 4:13 ` [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel elena.ufimtseva
@ 2020-05-12 12:35 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 12:35 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
On Wed, Apr 22, 2020 at 09:13:53PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Add "socket" object property which initializes the communication channel
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> ---
> hw/proxy/qemu-proxy.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
> index bf6c4117ef..40bf56fd37 100644
> --- a/hw/proxy/qemu-proxy.c
> +++ b/hw/proxy/qemu-proxy.c
> @@ -14,6 +14,25 @@
> #include "hw/proxy/qemu-proxy.h"
> #include "hw/pci/pci.h"
>
> +static void proxy_set_socket(Object *obj, const char *str, Error **errp)
> +{
> + PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
> +
> + pdev->socket = atoi(str);
> +
> + mpqemu_init_channel(pdev->mpqemu_link, &pdev->mpqemu_link->com,
> + pdev->socket);
If mpqemu_link objects are not going to use QOM's object-oriented
features then a plain C struct is fine. There is no need to define a QOM
type for mpqemu_link in an earlier patch.
> +}
> +
> +static void proxy_init(Object *obj)
> +{
> + PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
> +
> + pdev->mpqemu_link = mpqemu_link_create();
> +
> + object_property_add_str(obj, "socket", NULL, proxy_set_socket, NULL);
Please use a qdev property like vhost-vsock.c's vhostfd and call it
either "fd" so it's clear this is the file descriptor.
monitor_fd_param() should be used to parse the fd string at .realize()
time.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 17/36] multi-process: introduce proxy object
2020-05-12 12:23 ` Stefan Hajnoczi
@ 2020-05-12 12:35 ` Jag Raman
0 siblings, 0 replies; 94+ messages in thread
From: Jag Raman @ 2020-05-12 12:35 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, swapnil.ingle, John G Johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
> On May 12, 2020, at 8:23 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Wed, Apr 22, 2020 at 09:13:52PM -0700, elena.ufimtseva@oracle.com wrote:
>> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>>
>> Defines a PCI Device proxy object as a parent of TYPE_PCI_DEVICE.
>
> s/parent/child/
>
>>
>> PCI Proxy Object registers as a PCI device with QEMU and forwards all
>> PCI accesses to the remote process using the communication channel.
>
> Please include that functionality in this patch. The code below just
> sets up a skeleton PCI device. There is no code that forwards accesses
> to the remote process.
>
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> ---
>> MAINTAINERS | 3 ++
>> hw/Makefile.objs | 2 ++
>> hw/proxy/Makefile.objs | 1 +
>> hw/proxy/qemu-proxy.c | 56 +++++++++++++++++++++++++++++++++++
>> include/hw/proxy/qemu-proxy.h | 46 ++++++++++++++++++++++++++++
>> include/io/mpqemu-link.h | 1 +
>> 6 files changed, 109 insertions(+)
>> create mode 100644 hw/proxy/Makefile.objs
>> create mode 100644 hw/proxy/qemu-proxy.c
>> create mode 100644 include/hw/proxy/qemu-proxy.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 96f8d7ff19..3da3dcd311 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2866,6 +2866,9 @@ F: include/remote/machine.h
>> F: remote/machine.c
>> F: include/remote/memory.h
>> F: remote/memory.c
>> +F: hw/proxy/Makefile.objs
>> +F: hw/proxy/qemu-proxy.c
>> +F: include/hw/proxy/qemu-proxy.h
>
> It's a generic PCI device. hw/pci/proxy.c would be a good location for
> it.
>
> By the way an alternative to the "proxy"/"remote" terminology is
> RemotePCIClient/RemotePCIServer. That makes it more obvious that "proxy"
> is related the "remote" feature. Feel free to keep the existing
> terminology, I just wanted to suggest another possibility.
OK, got it.
>
>>
>> Build and test automation
>> -------------------------
>> diff --git a/hw/Makefile.objs b/hw/Makefile.objs
>> index af9235b6f2..7b489b12a5 100644
>> --- a/hw/Makefile.objs
>> +++ b/hw/Makefile.objs
>> @@ -45,6 +45,8 @@ endif
>> common-obj-y += $(devices-dirs-y)
>> obj-y += $(devices-dirs-y)
>>
>> +common-obj-$(CONFIG_MPQEMU) += proxy/
>> +
>> remote-pci-obj-$(CONFIG_MPQEMU) += core/
>> remote-pci-obj-$(CONFIG_MPQEMU) += block/
>> remote-pci-obj-$(CONFIG_MPQEMU) += pci/
>> diff --git a/hw/proxy/Makefile.objs b/hw/proxy/Makefile.objs
>> new file mode 100644
>> index 0000000000..eb81624cf8
>> --- /dev/null
>> +++ b/hw/proxy/Makefile.objs
>> @@ -0,0 +1 @@
>> +common-obj-$(CONFIG_MPQEMU) += qemu-proxy.o
>> diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
>> new file mode 100644
>> index 0000000000..bf6c4117ef
>> --- /dev/null
>> +++ b/hw/proxy/qemu-proxy.c
>> @@ -0,0 +1,56 @@
>> +/*
>> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + *
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "qemu-common.h"
>> +
>> +#include "qapi/error.h"
>> +#include "io/mpqemu-link.h"
>> +#include "hw/proxy/qemu-proxy.h"
>> +#include "hw/pci/pci.h"
>> +
>> +static void pci_proxy_dev_realize(PCIDevice *device, Error **errp)
>> +{
>> + PCIProxyDev *dev = PCI_PROXY_DEV(device);
>> + PCIProxyDevClass *k = PCI_PROXY_DEV_GET_CLASS(dev);
>> + Error *local_err = NULL;
>> +
>> + if (k->realize) {
>
> Will anything inherit from this class? I thought this is the remote PCI
> client that can acts as a stand-in for all remote PCI devices, so it's
> not clear why it's acting as a base class here.
No one is inheriting from this class anymore. This is code from before
when that was the case. We could remove this.
>
>> diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
>> index d46cb81058..73cc59b874 100644
>> --- a/include/io/mpqemu-link.h
>> +++ b/include/io/mpqemu-link.h
>> @@ -14,6 +14,7 @@
>> #include "qemu/osdep.h"
>> #include "qemu-common.h"
>>
>> +#include "sys/eventfd.h"
>
> Why? Nothing in this patch uses this header.
OK, got it.
Thanks!
—
Jag
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process
2020-04-23 4:13 ` [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process elena.ufimtseva
@ 2020-05-12 12:54 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 12:54 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 5324 bytes --]
On Wed, Apr 22, 2020 at 09:13:54PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> Send a message to the remote process to connect PCI device with the
> corresponding Proxy object in QEMU
The CONNECT_DEV message is no longer necessary with a 1 socket per
device architecture. Connecting to a specific UNIX domain socket (e.g.
vm001/lsi-scsi-1.sock) already identifies which device the proxy wishes
to talk to.
Each device should have an mpqemu link that accepts client connections.
You can either do that in the main loop or you can use IOThread to run
dedicated per-device threads.
>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> ---
> hw/proxy/qemu-proxy.c | 34 +++++++++++++++++++++++++++++++
> include/io/mpqemu-link.h | 5 +++++
> io/mpqemu-link.c | 3 +++
> remote/remote-main.c | 43 ++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 85 insertions(+)
>
> diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
> index 40bf56fd37..9b5e429a88 100644
> --- a/hw/proxy/qemu-proxy.c
> +++ b/hw/proxy/qemu-proxy.c
> @@ -17,11 +17,45 @@
> static void proxy_set_socket(Object *obj, const char *str, Error **errp)
> {
> PCIProxyDev *pdev = PCI_PROXY_DEV(obj);
> + DeviceState *dev = DEVICE(obj);
> + MPQemuMsg msg = { 0 };
> + int wait, fd[2];
>
> pdev->socket = atoi(str);
>
> mpqemu_init_channel(pdev->mpqemu_link, &pdev->mpqemu_link->com,
> pdev->socket);
> +
> + if (socketpair(AF_UNIX, SOCK_STREAM, 0, fd)) {
> + error_setg(errp, "Failed to create socket for device channel");
> + return;
> + }
This extra connection can be removed. The reasons for having it have
gone away now that there is just 1 device per socket.
> +
> + wait = GET_REMOTE_WAIT;
> +
> + msg.cmd = CONNECT_DEV;
> + msg.bytestream = 1;
> + msg.data2 = (uint8_t *)g_strdup(dev->id);
> + msg.size = sizeof(msg.data2);
The g_strdup() is unnecessary, dev->id can be used directly.
Should msg.size be strlen(dev->id) instead of sizeof(msg.data2)?
> + msg.num_fds = 2;
> + msg.fds[0] = wait;
> + msg.fds[1] = fd[1];
> +
> + mpqemu_msg_send(&msg, pdev->mpqemu_link->com);
> +
> + if (wait_for_remote(wait)) {
> + error_setg(errp, "Failed to connect device to the remote");
> + close(fd[0]);
> + } else {
> + mpqemu_init_channel(pdev->mpqemu_link, &pdev->mpqemu_link->dev,
> + fd[0]);
> + }
> +
> + PUT_REMOTE_WAIT(wait);
> +
> + close(fd[1]);
> +
> + g_free(msg.data2);
> }
>
> static void proxy_init(Object *obj)
> diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
> index 73cc59b874..ebae9afc45 100644
> --- a/include/io/mpqemu-link.h
> +++ b/include/io/mpqemu-link.h
> @@ -38,6 +38,7 @@
> typedef enum {
> INIT = 0,
> SYNC_SYSMEM,
> + CONNECT_DEV,
> MAX,
> } mpqemu_cmd_t;
>
> @@ -120,8 +121,12 @@ struct MPQemuLinkState {
> GMainLoop *loop;
>
> MPQemuChannel *com;
> + MPQemuChannel *dev;
>
> mpqemu_link_callback callback;
> +
> + void *opaque;
> + QemuThread thread;
> };
>
> MPQemuLinkState *mpqemu_link_create(void);
> diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
> index 3f81cef96e..f780b65181 100644
> --- a/io/mpqemu-link.c
> +++ b/io/mpqemu-link.c
> @@ -46,6 +46,9 @@ MPQemuLinkState *mpqemu_link_create(void)
> MPQemuLinkState *link = MPQEMU_LINK(object_new(TYPE_MPQEMU_LINK));
>
> link->com = NULL;
> + link->dev = NULL;
> +
> + link->opaque = NULL;
>
> return link;
> }
> diff --git a/remote/remote-main.c b/remote/remote-main.c
> index dbd6ad2529..f541baae6a 100644
> --- a/remote/remote-main.c
> +++ b/remote/remote-main.c
> @@ -35,6 +35,9 @@
> #include "exec/ramlist.h"
> #include "remote/remote-common.h"
>
> +static void process_msg(GIOCondition cond, MPQemuLinkState *link,
> + MPQemuChannel *chan);
> +
> static MPQemuLinkState *mpqemu_link;
>
> gchar *print_pid_exec(gchar *str)
> @@ -48,6 +51,43 @@ gchar *print_pid_exec(gchar *str)
> return str;
> }
>
> +#define LINK_TO_DEV(link) ((PCIDevice *)link->opaque)
> +
> +static gpointer dev_thread(gpointer data)
> +{
> + MPQemuLinkState *link = data;
> +
> + mpqemu_start_coms(link, link->dev);
> +
> + return NULL;
> +}
> +
> +static void process_connect_dev_msg(MPQemuMsg *msg)
> +{
> + char *devid = (char *)msg->data2;
Input validation is missing for this message. We may not have data2 or
it may not have a NUL-terminator.
> + MPQemuLinkState *link = NULL;
> + DeviceState *dev = NULL;
> + int wait = msg->fds[0];
msg->num_fds wasn't checked.
> + int ret = 0;
> +
> + dev = qdev_find_recursive(sysbus_get_default(), devid);
> + if (!dev) {
> + ret = 0xff;
> + goto exit;
> + }
> +
> + link = mpqemu_link_create();
> + link->opaque = (void *)PCI_DEVICE(dev);
Missing check to see if dev is a PCIDevice subclass.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to the remote process
2020-04-23 4:13 ` [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to " elena.ufimtseva
@ 2020-05-12 13:50 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 13:50 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]
On Wed, Apr 22, 2020 at 09:13:55PM -0700, elena.ufimtseva@oracle.com wrote:
> +static int config_op_send(PCIProxyDev *dev, uint32_t addr, uint32_t *val, int l,
> + unsigned int op)
> +{
> + MPQemuMsg msg;
> + struct conf_data_msg conf_data;
> + int wait;
> +
> + memset(&msg, 0, sizeof(MPQemuMsg));
> + conf_data.addr = addr;
> + conf_data.val = (op == PCI_CONFIG_WRITE) ? *val : 0;
> + conf_data.l = l;
> +
> + msg.data2 = (uint8_t *)&conf_data;
> + if (!msg.data2) {
> + return -ENOMEM;
This can never happen since conf_data is on the stack.
> + }
> +
> + msg.size = sizeof(conf_data);
> + msg.cmd = op;
> + msg.bytestream = 1;
> +
> + if (op == PCI_CONFIG_WRITE) {
> + msg.num_fds = 0;
> + } else {
> + /* TODO: Dont create fd each time for send. */
> + wait = GET_REMOTE_WAIT;
> + msg.num_fds = 1;
> + msg.fds[0] = wait;
> + }
> +
> + mpqemu_msg_send(&msg, dev->mpqemu_link->dev);
> +
> + if (op == PCI_CONFIG_READ) {
Are you sure it's correct for writes to be posted instead of waiting for
completion?
> + *val = (uint32_t)wait_for_remote(wait);
> + PUT_REMOTE_WAIT(wait);
> + }
> +
> + return 0;
> +}
> +
> +static uint32_t pci_proxy_read_config(PCIDevice *d, uint32_t addr, int len)
> +{
> + uint32_t val;
> +
> + (void)pci_default_read_config(d, addr, len);
Please add a comment explaining why this local read is necessary.
> +
> + config_op_send(PCI_PROXY_DEV(d), addr, &val, len, PCI_CONFIG_READ);
> +
> + return val;
> +}
> +
> +static void pci_proxy_write_config(PCIDevice *d, uint32_t addr, uint32_t val,
> + int l)
> +{
> + pci_default_write_config(d, addr, val, l);
Please add a comment explaining why this local write is necessary.
> +
> + config_op_send(PCI_PROXY_DEV(d), addr, &val, l, PCI_CONFIG_WRITE);
> +}
...
> diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
> index f780b65181..ef4a07b81a 100644
> --- a/io/mpqemu-link.c
> +++ b/io/mpqemu-link.c
> @@ -381,6 +381,12 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
> return false;
> }
> break;
> + case PCI_CONFIG_WRITE:
> + case PCI_CONFIG_READ:
> + if (msg->size != sizeof(struct conf_data_msg)) {
> + return false;
> + }
conf_data_msg.l is not validated.
> + break;
> default:
> break;
> }
> diff --git a/remote/remote-main.c b/remote/remote-main.c
> index f541baae6a..834574e172 100644
> --- a/remote/remote-main.c
> +++ b/remote/remote-main.c
> @@ -53,6 +53,32 @@ gchar *print_pid_exec(gchar *str)
>
> #define LINK_TO_DEV(link) ((PCIDevice *)link->opaque)
>
> +static void process_config_write(PCIDevice *dev, MPQemuMsg *msg)
> +{
> + struct conf_data_msg *conf = (struct conf_data_msg *)msg->data2;
> +
> + qemu_mutex_lock_iothread();
The qemu_mutex_lock_iothread() can be dropped once this is integrated in
to QEMU's event loop.
> + pci_default_write_config(dev, conf->addr, conf->val, conf->l);
It is not safe to call this function with arbitrary addr input values.
> + qemu_mutex_unlock_iothread();
> +}
> +
> +static void process_config_read(PCIDevice *dev, MPQemuMsg *msg)
> +{
> + struct conf_data_msg *conf = (struct conf_data_msg *)msg->data2;
> + uint32_t val;
> + int wait;
> +
> + wait = msg->fds[0];
> +
> + qemu_mutex_lock_iothread();
> + val = pci_default_read_config(dev, conf->addr, conf->l);
It is not safe to call this function with arbitrary addr input values.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints
2020-04-23 4:13 ` [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints elena.ufimtseva
@ 2020-05-12 14:19 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 14:19 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]
On Wed, Apr 22, 2020 at 09:13:56PM -0700, elena.ufimtseva@oracle.com wrote:
> +uint64_t proxy_default_bar_read(void *opaque, hwaddr addr, unsigned size)
> +{
> + ProxyMemoryRegion *pmr = opaque;
> + uint64_t val;
> +
> + send_bar_access_msg(pmr->dev, &pmr->mr, false, addr, &val, size,
> + pmr->memory);
> +
> + return val;
Indentation is should be 4 spaces.
> @@ -43,4 +54,9 @@ typedef struct PCIProxyDevClass {
> char *command;
> } PCIProxyDevClass;
>
> +void proxy_default_bar_write(void *opaque, hwaddr addr, uint64_t val,
> + unsigned size);
> +
> +uint64_t proxy_default_bar_read(void *opaque, hwaddr addr, unsigned size);
"default" is probably not appropriate here. This isn't a base class'
default implementation that child classes override.
> @@ -114,6 +115,77 @@ exit:
> notify_proxy(wait, ret);
> }
>
> +/* TODO: confirm memtx attrs. */
> +static void process_bar_write(MPQemuMsg *msg, Error **errp)
> +{
> + bar_access_msg_t *bar_access = &msg->data1.bar_access;
> + AddressSpace *as =
> + bar_access->memory ? &address_space_memory : &address_space_io;
> + MemTxResult res;
> +
> + assert(is_power_of_2(bar_access->size) &&
> + bar_access->size <= sizeof(uint64_t));
Please return an error instead of asserting. At the moment it doesn't
matter much but this will be necessary so that a process hosting remote
devices for multiple guests cannot be killed by one malicious guest.
> +
> + res = address_space_rw(as, bar_access->addr, MEMTXATTRS_UNSPECIFIED,
> + (uint8_t *)&bar_access->val, bar_access->size,
Missing uint64_t val to void* conversion code.
For example, if bar_access->size is 1 then this fails on big-endian
hosts because &bar_access->val is the address of the most-significant
byte in uint64_t val:
uint64_t val = 1;
Now we have the following memory layout on big-endian hosts:
val = 00 00 00 00 00 00 00 01
^-------------- &val
We actually wanted a 1-byte write of 0x01 and not 0x00.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory
2020-04-23 4:13 ` [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory elena.ufimtseva
@ 2020-05-12 15:07 ` Stefan Hajnoczi
2020-05-12 15:49 ` Dr. David Alan Gilbert
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 15:07 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 5186 bytes --]
On Wed, Apr 22, 2020 at 09:13:57PM -0700, elena.ufimtseva@oracle.com wrote:
> diff --git a/hw/proxy/memory-sync.c b/hw/proxy/memory-sync.c
> new file mode 100644
> index 0000000000..b3f57747f3
> --- /dev/null
> +++ b/hw/proxy/memory-sync.c
> @@ -0,0 +1,217 @@
> +/*
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include <sys/types.h>
> +#include <stdio.h>
> +#include <string.h>
These headers should already be included by "qemu/osdep.h".
> +static void proxy_ml_region_addnop(MemoryListener *listener,
> + MemoryRegionSection *section)
> +{
> + RemoteMemSync *sync = container_of(listener, RemoteMemSync, listener);
> + bool need_add = true;
> + uint64_t mrs_size, mrs_gpa, mrs_page;
> + uintptr_t mrs_host;
> + RAMBlock *mrs_rb;
> + MemoryRegionSection *prev_sec;
> +
> + if (!(memory_region_is_ram(section->mr) &&
> + !memory_region_is_rom(section->mr))) {
> + return;
> + }
> +
> + mrs_rb = section->mr->ram_block;
> + mrs_page = (uint64_t)qemu_ram_pagesize(mrs_rb);
> + mrs_size = int128_get64(section->size);
> + mrs_gpa = section->offset_within_address_space;
> + mrs_host = (uintptr_t)memory_region_get_ram_ptr(section->mr) +
> + section->offset_within_region;
These variables are only used in the if (sync->n_mr_sections) case. This
function could be split into a something like this:
static void proxy_ml_region_addnop(MemoryListener *listener,
MemoryRegionSection *section)
RemoteMemSync *sync = container_of(listener, RemoteMemSync, listener);
if (!(memory_region_is_ram(section->mr) &&
!memory_region_is_rom(section->mr))) {
return;
}
if (try_merge(sync, section)) {
return;
}
...add new section...
}
And the try_merge() helper function has the rest of the code:
/* Returns true if the section was merged */
static bool try_merge(RemoteMemSync *sync, MemoryRegionSection *section)
{
if (sync->n_mr_sections == 0) {
return false;
}
...most of the code...
}
> +
> + if (get_fd_from_hostaddr(mrs_host, NULL) <= 0) {
0 is a valid fd number, the comparison should probably be < 0?
> + return;
> + }
> +
> + mrs_host = mrs_host & ~(mrs_page - 1);
> + mrs_gpa = mrs_gpa & ~(mrs_page - 1);
> + mrs_size = ROUND_UP(mrs_size, mrs_page);
Why is it necessary to align to the RAM block's page size?
Can mrs_host and mrs_size be misaligned to the RAM block's page size?
Why round the *guest* physical address down using the *host* page size?
> +
> + if (sync->n_mr_sections) {
> + prev_sec = sync->mr_sections + (sync->n_mr_sections - 1);
> + uint64_t prev_gpa_start = prev_sec->offset_within_address_space;
> + uint64_t prev_size = int128_get64(prev_sec->size);
> + uint64_t prev_gpa_end = range_get_last(prev_gpa_start, prev_size);
> + uint64_t prev_host_start =
> + (uintptr_t)memory_region_get_ram_ptr(prev_sec->mr) +
> + prev_sec->offset_within_region;
> + uint64_t prev_host_end = range_get_last(prev_host_start, prev_size);
Is it okay not to do the page alignment stuff for the previous
MemoryRegionSection?
> +void deconfigure_memory_sync(RemoteMemSync *sync)
> +{
> + memory_listener_unregister(&sync->listener);
> +}
This function is unused? It must be tied into the mpqemu_link lifecycle.
It must be possible to hot plug/unplug proxy PCI devices without memory
leaks or use-after-frees.
> diff --git a/include/hw/proxy/memory-sync.h b/include/hw/proxy/memory-sync.h
> new file mode 100644
> index 0000000000..d8329c9b52
> --- /dev/null
> +++ b/include/hw/proxy/memory-sync.h
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#ifndef MEMORY_SYNC_H
> +#define MEMORY_SYNC_H
> +
> +#include <sys/types.h>
> +
> +#include "qemu/osdep.h"
> +#include "qom/object.h"
> +#include "exec/memory.h"
> +#include "io/mpqemu-link.h"
> +
> +#define TYPE_MEMORY_LISTENER "memory-listener"
This name is too generic. There is already a C struct called
MemoryListener. Please call this class "remote-memory-sync".
I'm not sure if a QOM object is needed here. Can this just be a plain C
struct? If you're not using QOM object-orientated features then there is
no need to define a QOM object.
> @@ -39,8 +40,13 @@ typedef struct ProxyMemoryRegion {
> struct PCIProxyDev {
> PCIDevice parent_dev;
>
> + int n_mr_sections;
> + MemoryRegionSection *mr_sections;
Is it necessary to duplicate these fields here since a RemoteMemSync
field is also being added and it contains these same fields?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory
2020-05-12 15:07 ` Stefan Hajnoczi
@ 2020-05-12 15:49 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 94+ messages in thread
From: Dr. David Alan Gilbert @ 2020-05-12 15:49 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: elena.ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, jag.raman, quintela, mst, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> On Wed, Apr 22, 2020 at 09:13:57PM -0700, elena.ufimtseva@oracle.com wrote:
> > diff --git a/hw/proxy/memory-sync.c b/hw/proxy/memory-sync.c
> > new file mode 100644
> > index 0000000000..b3f57747f3
> > --- /dev/null
> > +++ b/hw/proxy/memory-sync.c
> > @@ -0,0 +1,217 @@
> > +/*
> > + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#include <sys/types.h>
> > +#include <stdio.h>
> > +#include <string.h>
>
> These headers should already be included by "qemu/osdep.h".
>
> > +static void proxy_ml_region_addnop(MemoryListener *listener,
> > + MemoryRegionSection *section)
> > +{
> > + RemoteMemSync *sync = container_of(listener, RemoteMemSync, listener);
> > + bool need_add = true;
> > + uint64_t mrs_size, mrs_gpa, mrs_page;
> > + uintptr_t mrs_host;
> > + RAMBlock *mrs_rb;
> > + MemoryRegionSection *prev_sec;
> > +
> > + if (!(memory_region_is_ram(section->mr) &&
> > + !memory_region_is_rom(section->mr))) {
> > + return;
> > + }
> > +
> > + mrs_rb = section->mr->ram_block;
> > + mrs_page = (uint64_t)qemu_ram_pagesize(mrs_rb);
> > + mrs_size = int128_get64(section->size);
> > + mrs_gpa = section->offset_within_address_space;
> > + mrs_host = (uintptr_t)memory_region_get_ram_ptr(section->mr) +
> > + section->offset_within_region;
>
> These variables are only used in the if (sync->n_mr_sections) case. This
> function could be split into a something like this:
>
> static void proxy_ml_region_addnop(MemoryListener *listener,
> MemoryRegionSection *section)
> RemoteMemSync *sync = container_of(listener, RemoteMemSync, listener);
>
> if (!(memory_region_is_ram(section->mr) &&
> !memory_region_is_rom(section->mr))) {
> return;
> }
>
> if (try_merge(sync, section)) {
> return;
> }
>
> ...add new section...
> }
>
> And the try_merge() helper function has the rest of the code:
>
> /* Returns true if the section was merged */
> static bool try_merge(RemoteMemSync *sync, MemoryRegionSection *section)
> {
> if (sync->n_mr_sections == 0) {
> return false;
> }
>
> ...most of the code...
> }
>
> > +
> > + if (get_fd_from_hostaddr(mrs_host, NULL) <= 0) {
>
> 0 is a valid fd number, the comparison should probably be < 0?
>
> > + return;
> > + }
> > +
> > + mrs_host = mrs_host & ~(mrs_page - 1);
> > + mrs_gpa = mrs_gpa & ~(mrs_page - 1);
> > + mrs_size = ROUND_UP(mrs_size, mrs_page);
>
> Why is it necessary to align to the RAM block's page size?
>
> Can mrs_host and mrs_size be misaligned to the RAM block's page size?
>
> Why round the *guest* physical address down using the *host* page size?
That sounds like the type of magic we do for postcopy; where we can only
'place' pages atomically on a host page boundary.
Dave
> > +
> > + if (sync->n_mr_sections) {
> > + prev_sec = sync->mr_sections + (sync->n_mr_sections - 1);
> > + uint64_t prev_gpa_start = prev_sec->offset_within_address_space;
> > + uint64_t prev_size = int128_get64(prev_sec->size);
> > + uint64_t prev_gpa_end = range_get_last(prev_gpa_start, prev_size);
> > + uint64_t prev_host_start =
> > + (uintptr_t)memory_region_get_ram_ptr(prev_sec->mr) +
> > + prev_sec->offset_within_region;
> > + uint64_t prev_host_end = range_get_last(prev_host_start, prev_size);
>
> Is it okay not to do the page alignment stuff for the previous
> MemoryRegionSection?
>
> > +void deconfigure_memory_sync(RemoteMemSync *sync)
> > +{
> > + memory_listener_unregister(&sync->listener);
> > +}
>
> This function is unused? It must be tied into the mpqemu_link lifecycle.
> It must be possible to hot plug/unplug proxy PCI devices without memory
> leaks or use-after-frees.
>
> > diff --git a/include/hw/proxy/memory-sync.h b/include/hw/proxy/memory-sync.h
> > new file mode 100644
> > index 0000000000..d8329c9b52
> > --- /dev/null
> > +++ b/include/hw/proxy/memory-sync.h
> > @@ -0,0 +1,37 @@
> > +/*
> > + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#ifndef MEMORY_SYNC_H
> > +#define MEMORY_SYNC_H
> > +
> > +#include <sys/types.h>
> > +
> > +#include "qemu/osdep.h"
> > +#include "qom/object.h"
> > +#include "exec/memory.h"
> > +#include "io/mpqemu-link.h"
> > +
> > +#define TYPE_MEMORY_LISTENER "memory-listener"
>
> This name is too generic. There is already a C struct called
> MemoryListener. Please call this class "remote-memory-sync".
>
> I'm not sure if a QOM object is needed here. Can this just be a plain C
> struct? If you're not using QOM object-orientated features then there is
> no need to define a QOM object.
>
> > @@ -39,8 +40,13 @@ typedef struct ProxyMemoryRegion {
> > struct PCIProxyDev {
> > PCIDevice parent_dev;
> >
> > + int n_mr_sections;
> > + MemoryRegionSection *mr_sections;
>
> Is it necessary to duplicate these fields here since a RemoteMemSync
> field is also being added and it contains these same fields?
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq
2020-04-23 4:13 ` [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq elena.ufimtseva
@ 2020-05-12 15:57 ` Stefan Hajnoczi
2020-05-12 16:12 ` Stefan Hajnoczi
1 sibling, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 15:57 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]
On Wed, Apr 22, 2020 at 09:13:58PM -0700, elena.ufimtseva@oracle.com wrote:
> diff --git a/include/remote/iohub.h b/include/remote/iohub.h
> new file mode 100644
> index 0000000000..7a488a8c38
> --- /dev/null
> +++ b/include/remote/iohub.h
> @@ -0,0 +1,50 @@
> +/*
> + * IO Hub for remote device
> + *
> + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#ifndef REMOTE_IOHUB_H
> +#define REMOTE_IOHUB_H
> +
> +#include <sys/types.h>
> +
> +#include "qemu/osdep.h"
> +#include "hw/pci/pci.h"
> +#include "qemu/event_notifier.h"
> +#include "qemu/thread-posix.h"
> +#include "io/mpqemu-link.h"
> +
> +#define REMOTE_IOHUB_NB_PIRQS 8
We only use pirqs 4-7 based on the (slot + intx) % 4 + 4 formula. Why is
it necessary to reserve 8 irqs?
> +
> +#define REMOTE_IOHUB_DEV 31
> +#define REMOTE_IOHUB_FUNC 0
> +
> +#define TYPE_REMOTE_IOHUB_DEVICE "remote-iohub"
> +#define REMOTE_IOHUB_DEVICE(obj) \
> + OBJECT_CHECK(RemoteIOHubState, (obj), TYPE_REMOTE_IOHUB_DEVICE)
> +
> +typedef struct ResampleToken {
> + void *iohub;
> + int pirq;
> +} ResampleToken;
> +
> +typedef struct RemoteIOHubState {
> + PCIDevice d;
> + uint8_t irq_num[PCI_SLOT_MAX][PCI_NUM_PINS];
This is a fixed mapping based on a formula. Is there any need to store
it in an array?
> diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
> index 5cb93fc47b..ea519a980e 100644
> --- a/io/mpqemu-link.c
> +++ b/io/mpqemu-link.c
> @@ -389,6 +389,7 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
> break;
> case BAR_WRITE:
> case BAR_READ:
> + case SET_IRQFD:
> if (msg->size != sizeof(msg->data1)) {
Wait, this is checking for sizeof(msg->data1) but the message defines
its own struct!
> +void process_set_irqfd_msg(PCIDevice *pci_dev, MPQemuMsg *msg)
> +{
> + RemMachineState *machine = REMOTE_MACHINE(current_machine);
> + RemoteIOHubState *iohub = machine->iohub;
> + int pirq = remote_iohub_map_irq(pci_dev, msg->data1.set_irqfd.intx);
intx has not been validated.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process
2020-04-23 4:13 ` [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process elena.ufimtseva
@ 2020-05-12 16:07 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 16:07 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
On Wed, Apr 22, 2020 at 09:13:59PM -0700, elena.ufimtseva@oracle.com wrote:
> @@ -291,3 +299,79 @@ const MemoryRegionOps proxy_default_ops = {
> .max_access_size = 1,
> },
> };
> +
> +static void probe_pci_info(PCIDevice *dev)
> +{
> + PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
> + DeviceClass *dc = DEVICE_CLASS(pc);
> + PCIProxyDev *pdev = PCI_PROXY_DEV(dev);
> + MPQemuLinkState *mpqemu_link = pdev->mpqemu_link;
> + MPQemuMsg msg, ret;
> + uint32_t orig_val, new_val, class;
> + uint8_t type;
> + int i, size;
> + char *name;
> +
> + memset(&msg, 0, sizeof(MPQemuMsg));
> + msg.bytestream = 0;
> + msg.size = 0;
> + msg.cmd = GET_PCI_INFO;
> + mpqemu_msg_send(&msg, mpqemu_link->dev);
> +
> + mpqemu_msg_recv(&ret, mpqemu_link->dev);
> +
> + pc->vendor_id = ret.data1.ret_pci_info.vendor_id;
> + pc->device_id = ret.data1.ret_pci_info.device_id;
> + pc->class_id = ret.data1.ret_pci_info.class_id;
> + pc->subsystem_id = ret.data1.ret_pci_info.subsystem_id;
> +
Why introduce the GET_PCI_INFO/RET_PCI_INFO messages when the same
information can already be fetched using PCI_CONFIG_READ?
> + config_op_send(pdev, 11, &class, 1, PCI_CONFIG_READ);
Please use constants like PCI_CLASS_DEVICE instead of magic numbers.
> diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
> index 14e4be2bd0..102c736705 100644
> --- a/include/io/mpqemu-link.h
> +++ b/include/io/mpqemu-link.h
> @@ -48,6 +48,8 @@ typedef enum {
> BAR_WRITE,
> BAR_READ,
> SET_IRQFD,
> + GET_PCI_INFO,
> + RET_PCI_INFO,
Ah, I see reply messages are being used after all. I suggest dropping
the eventfd wait mechanism and using reply messages instead. Otherwise
you need to duplicate the wait timeout for reply messages. Using
temporary eventfds is more complex and maybe also slower.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq
2020-04-23 4:13 ` [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq elena.ufimtseva
2020-05-12 15:57 ` Stefan Hajnoczi
@ 2020-05-12 16:12 ` Stefan Hajnoczi
1 sibling, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 16:12 UTC (permalink / raw)
To: elena.ufimtseva
Cc: fam, john.g.johnson, swapnil.ingle, mst, qemu-devel, kraxel,
jag.raman, quintela, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, thanos.makatos, rth,
kwolf, berrange, mreitz, ross.lagerwall, marcandre.lureau,
pbonzini
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
On Wed, Apr 22, 2020 at 09:13:58PM -0700, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
>
> IOHUB object is added to manage PCI IRQs. It uses KVM_IRQFD
> ioctl to create irqfd to injecting PCI interrupts to the guest.
> IOHUB object forwards the irqfd to the remote process. Remote process
> uses this fd to directly send interrupts to the guest, bypassing QEMU.
>
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> ---
> MAINTAINERS | 2 +
> Makefile.target | 1 +
> hw/Makefile.objs | 2 -
> hw/proxy/Makefile.objs | 1 -
> hw/proxy/qemu-proxy.c | 52 ++++++++++++
> include/hw/pci/pci_ids.h | 3 +
> include/hw/proxy/qemu-proxy.h | 8 ++
> include/io/mpqemu-link.h | 8 ++
> include/remote/iohub.h | 50 ++++++++++++
> include/remote/machine.h | 2 +
> io/mpqemu-link.c | 1 +
> remote/Makefile.objs | 1 +
> remote/iohub.c | 148 ++++++++++++++++++++++++++++++++++
> remote/machine.c | 15 ++++
> remote/remote-main.c | 4 +
> 15 files changed, 295 insertions(+), 3 deletions(-)
> delete mode 100644 hw/proxy/Makefile.objs
> create mode 100644 include/remote/iohub.h
> create mode 100644 remote/iohub.c
Does this mean MSI-X is not supported?
For legacy device emulation INTx is fine but for modern devices MSI-X is
used for better performance (multiqueue, etc).
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-05-11 19:30 ` Jag Raman
@ 2020-05-12 16:13 ` Stefan Hajnoczi
2020-05-12 16:55 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-12 16:13 UTC (permalink / raw)
To: Jag Raman
Cc: Elena Ufimtseva, fam, Swapnil Ingle, john.g.johnson, qemu-devel,
kraxel, quintela, Michael S. Tsirkin, armbru, kanth.ghatraju,
felipe, thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
stefanha, pbonzini, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]
On Mon, May 11, 2020 at 03:30:50PM -0400, Jag Raman wrote:
> > On May 11, 2020, at 10:40 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > Hi,
> > Have you decided whether to drop the remote device program in favor of
> > using a softmmu make target?
> >
> > Is there anything in this series you'd like me to review before you send
> > the next revision?
>
> Hi Stefan,
>
> We are planning to drop the separate remote device program in the next
> revision. We are planning to use QEMU’s existing event loop instead of
> a separate event loop for the remote process, as well as the command
> line invocation you suggested in your feedback.
>
> We hope the following core patches look good to you, by and large:
> [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
> [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object
> [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints
> [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device
> [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process
> [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device
> [PATCH RESEND v6 17/36] multi-process: introduce proxy object
> [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel
> [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process
> [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to the remote process
> [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints
> [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory
> [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq
> [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process
I've completed the review of these patches. Looking forward to
discussing more.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 00/36] Initial support for multi-process qemu
2020-05-12 16:13 ` Stefan Hajnoczi
@ 2020-05-12 16:55 ` Jag Raman
0 siblings, 0 replies; 94+ messages in thread
From: Jag Raman @ 2020-05-12 16:55 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
kraxel, quintela, Michael S. Tsirkin, armbru, kanth.ghatraju,
felipe, thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
stefanha, thanos.makatos, rth, kwolf, berrange, mreitz,
ross.lagerwall, marcandre.lureau, pbonzini
> On May 12, 2020, at 12:13 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Mon, May 11, 2020 at 03:30:50PM -0400, Jag Raman wrote:
>>> On May 11, 2020, at 10:40 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>>
>>> Hi,
>>> Have you decided whether to drop the remote device program in favor of
>>> using a softmmu make target?
>>>
>>> Is there anything in this series you'd like me to review before you send
>>> the next revision?
>>
>> Hi Stefan,
>>
>> We are planning to drop the separate remote device program in the next
>> revision. We are planning to use QEMU’s existing event loop instead of
>> a separate event loop for the remote process, as well as the command
>> line invocation you suggested in your feedback.
>>
>> We hope the following core patches look good to you, by and large:
>> [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
>> [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object
>> [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints
>> [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device
>> [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process
>> [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device
>> [PATCH RESEND v6 17/36] multi-process: introduce proxy object
>> [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel
>> [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process
>> [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to the remote process
>> [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints
>> [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory
>> [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq
>> [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process
>
> I've completed the review of these patches. Looking forward to
> discussing more.
Thank you very much, Stefan!
We will incorporate the feedback we received from your review.
Thanks!
--
Jag
>
> Stefan
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-05-12 11:56 ` Jag Raman
@ 2020-05-13 8:40 ` Stefan Hajnoczi
2020-05-13 15:25 ` Igor Mammedov
0 siblings, 1 reply; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-13 8:40 UTC (permalink / raw)
To: Daniel Berrange
Cc: Elena Ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, Jag Raman, quintela, mst, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon, pbonzini,
rth, kwolf, mreitz, ross.lagerwall, marcandre.lureau,
thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
On Tue, May 12, 2020 at 07:56:33AM -0400, Jag Raman wrote:
>
>
> > On May 12, 2020, at 4:48 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
> >> From: Jagannathan Raman <jag.raman@oracle.com>
> >>
> >> Allow RAM MemoryRegion to be created from an offset in a file, instead
> >> of allocating at offset of 0 by default. This is needed to synchronize
> >> RAM between QEMU & remote process.
> >
> > Can you elaborate on why remote processes require the RAM to be offset
> > from zero ?
>
> Hi Daniel,
>
> As it turns out, the RAM is scattered across the physical address space
> (system_memory) of QEMU. Therefore, the system memory is composed
> of multiple sections of RAM, and some sections start at a non-zero RAM
> offset.
>
> As a result, the remote process needs the ability to map these RAM
> sections into system_memory.
To explain a bit more, my understanding is that the offset is
specifically for mmap(2). As Jag alluded to, multiple sections can use a
single backing RAM file. These sections have different offsets in the
file.
Jag, maybe you can include a concrete explanation like the following in
the commit description:
Launch QEMU like this:
qemu-system-x86_64 -mem-path /dev/shm -m 8G
There is only one RAM file descriptor:
$ cat /proc/$(pidof qemu)/fd
...
lrwx------. 1 stefanha stefanha 64 May 13 09:34 19 -> '/dev/shm/qemu_back_mem.pc.ram.7YAlqn (deleted)'
But the memory tree shows that single file is split into multiple ranges
of guest physical address space:
(qemu) info mtree
memory-region: system
0000000000000000-ffffffffffffffff (prio 0, i/o): system
0000000000000000-00000000bfffffff (prio 0, i/o): alias ram-below-4g @pc.ram 0000000000000000-00000000bfffffff
...
0000000100000000-000000023fffffff (prio 0, i/o): alias ram-above-4g @pc.ram 00000000c0000000-00000001ffffffff
This means QEMU needs to send two regions to the remote device process.
They both mmap the same file but from different starting file offsets.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints
2020-05-12 12:28 ` Jag Raman
@ 2020-05-13 8:43 ` Stefan Hajnoczi
0 siblings, 0 replies; 94+ messages in thread
From: Stefan Hajnoczi @ 2020-05-13 8:43 UTC (permalink / raw)
To: Jag Raman
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
kraxel, quintela, Michael S. Tsirkin, armbru, kanth.ghatraju,
felipe, thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
pbonzini, rth, kwolf, berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
On Tue, May 12, 2020 at 08:28:39AM -0400, Jag Raman wrote:
> > On May 12, 2020, at 6:21 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > On Wed, Apr 22, 2020 at 09:13:47PM -0700, elena.ufimtseva@oracle.com wrote:
> >> +uint64_t wait_for_remote(int efd)
> >> +{
> >> + struct pollfd pfd = { .fd = efd, .events = POLLIN };
> >> + uint64_t val;
> >> + int ret;
> >> +
> >> + ret = poll(&pfd, 1, 1000);
> >
> > This 1 second blocking operation is not allowed in an event loop since
> > it will stall any other event loop activity. If locks are held then
> > other threads may also be stalled.
> >
> > It's likely that this will need to change as part of the QEMU event loop
> > integration. Caller code can be kept mostly unchanged if you use
> > coroutines.
>
> In case the remote process has hung or terminated, the 1 second timeout
> ensures that the IO operation does not block for too long.
Timeouts are fine. They just need to be integrated into the event loop
instead of blocking it. That way other processing can continue while
waiting for the remote device process to respond or time out.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-05-13 8:40 ` Stefan Hajnoczi
@ 2020-05-13 15:25 ` Igor Mammedov
2020-05-13 20:08 ` Jag Raman
0 siblings, 1 reply; 94+ messages in thread
From: Igor Mammedov @ 2020-05-13 15:25 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Elena Ufimtseva, fam, swapnil.ingle, john.g.johnson, qemu-devel,
kraxel, Jag Raman, quintela, mst, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, dgilbert, liran.alon,
thanos.makatos, rth, kwolf, Daniel Berrange, mreitz,
ross.lagerwall, marcandre.lureau, pbonzini
On Wed, 13 May 2020 09:40:42 +0100
Stefan Hajnoczi <stefanha@redhat.com> wrote:
> On Tue, May 12, 2020 at 07:56:33AM -0400, Jag Raman wrote:
> >
> >
> > > On May 12, 2020, at 4:48 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >
> > > On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
> > >> From: Jagannathan Raman <jag.raman@oracle.com>
> > >>
> > >> Allow RAM MemoryRegion to be created from an offset in a file, instead
> > >> of allocating at offset of 0 by default. This is needed to synchronize
> > >> RAM between QEMU & remote process.
> > >
> > > Can you elaborate on why remote processes require the RAM to be offset
> > > from zero ?
> >
> > Hi Daniel,
> >
> > As it turns out, the RAM is scattered across the physical address space
> > (system_memory) of QEMU. Therefore, the system memory is composed
> > of multiple sections of RAM, and some sections start at a non-zero RAM
> > offset.
> >
> > As a result, the remote process needs the ability to map these RAM
> > sections into system_memory.
>
> To explain a bit more, my understanding is that the offset is
> specifically for mmap(2). As Jag alluded to, multiple sections can use a
> single backing RAM file. These sections have different offsets in the
> file.
>
> Jag, maybe you can include a concrete explanation like the following in
> the commit description:
>
> Launch QEMU like this:
>
> qemu-system-x86_64 -mem-path /dev/shm -m 8G
>
> There is only one RAM file descriptor:
>
> $ cat /proc/$(pidof qemu)/fd
> ...
> lrwx------. 1 stefanha stefanha 64 May 13 09:34 19 -> '/dev/shm/qemu_back_mem.pc.ram.7YAlqn (deleted)'
>
> But the memory tree shows that single file is split into multiple ranges
> of guest physical address space:
>
> (qemu) info mtree
> memory-region: system
> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
> 0000000000000000-00000000bfffffff (prio 0, i/o): alias ram-below-4g @pc.ram 0000000000000000-00000000bfffffff
> ...
> 0000000100000000-000000023fffffff (prio 0, i/o): alias ram-above-4g @pc.ram 00000000c0000000-00000001ffffffff
>
> This means QEMU needs to send two regions to the remote device process.
> They both mmap the same file but from different starting file offsets.
are we talking here about GPA offests her or about host offsets in mmaped host file?
If it's the later then above mtree doesn't show true picture (those entries are just aliases),
main guest RAM is allocated as a single continuous chunk (so far) which belongs
to a memory-backend.
> Stefan
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-05-13 15:25 ` Igor Mammedov
@ 2020-05-13 20:08 ` Jag Raman
2020-05-14 9:47 ` Igor Mammedov
2020-05-14 9:51 ` Dr. David Alan Gilbert
0 siblings, 2 replies; 94+ messages in thread
From: Jag Raman @ 2020-05-13 20:08 UTC (permalink / raw)
To: Igor Mammedov
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, Stefan Hajnoczi,
pbonzini, rth, kwolf, Daniel Berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
> On May 13, 2020, at 11:25 AM, Igor Mammedov <imammedo@redhat.com> wrote:
>
> On Wed, 13 May 2020 09:40:42 +0100
> Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
>> On Tue, May 12, 2020 at 07:56:33AM -0400, Jag Raman wrote:
>>>
>>>
>>>> On May 12, 2020, at 4:48 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>>
>>>> On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
>>>>> From: Jagannathan Raman <jag.raman@oracle.com>
>>>>>
>>>>> Allow RAM MemoryRegion to be created from an offset in a file, instead
>>>>> of allocating at offset of 0 by default. This is needed to synchronize
>>>>> RAM between QEMU & remote process.
>>>>
>>>> Can you elaborate on why remote processes require the RAM to be offset
>>>> from zero ?
>>>
>>> Hi Daniel,
>>>
>>> As it turns out, the RAM is scattered across the physical address space
>>> (system_memory) of QEMU. Therefore, the system memory is composed
>>> of multiple sections of RAM, and some sections start at a non-zero RAM
>>> offset.
>>>
>>> As a result, the remote process needs the ability to map these RAM
>>> sections into system_memory.
>>
>> To explain a bit more, my understanding is that the offset is
>> specifically for mmap(2). As Jag alluded to, multiple sections can use a
>> single backing RAM file. These sections have different offsets in the
>> file.
>>
>> Jag, maybe you can include a concrete explanation like the following in
>> the commit description:
>>
>> Launch QEMU like this:
>>
>> qemu-system-x86_64 -mem-path /dev/shm -m 8G
>>
>> There is only one RAM file descriptor:
>>
>> $ cat /proc/$(pidof qemu)/fd
>> ...
>> lrwx------. 1 stefanha stefanha 64 May 13 09:34 19 -> '/dev/shm/qemu_back_mem.pc.ram.7YAlqn (deleted)'
>>
>> But the memory tree shows that single file is split into multiple ranges
>> of guest physical address space:
>>
>> (qemu) info mtree
>> memory-region: system
>> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
>> 0000000000000000-00000000bfffffff (prio 0, i/o): alias ram-below-4g @pc.ram 0000000000000000-00000000bfffffff
>> ...
>> 0000000100000000-000000023fffffff (prio 0, i/o): alias ram-above-4g @pc.ram 00000000c0000000-00000001ffffffff
>>
>> This means QEMU needs to send two regions to the remote device process.
>> They both mmap the same file but from different starting file offsets.
>
> are we talking here about GPA offests her or about host offsets in mmaped host file?
> If it's the later then above mtree doesn't show true picture (those entries are just aliases),
> main guest RAM is allocated as a single continuous chunk (so far) which belongs
> to a memory-backend.
Thanks for the info about ‘mtree’ QMP option. We’ll use that to better explain the need for offset
during memory allocation.
As we can observe from the ‘mtree’ output, different sections of system memory vector into the
RAM. Since we have only one file descriptor available for all of RAM, we need to mmap() these
sections at different offsets within the memory file.
Hey Igor, the offset passed into the mmap() syscall is the offset within host file. Thanks for
pointing out that these are aliases. I believe the mmap() operation is equivalent to the “alias”
operation within MemoryRegion framework. We are sending the ‘fd’, ‘offset’ within the fd and
the size of these RAM regions to the remote device over the unix socket. Hopefully, this looks
good to you.
Thanks!
--
Jag
>
>> Stefan
>
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-05-13 20:08 ` Jag Raman
@ 2020-05-14 9:47 ` Igor Mammedov
2020-05-14 9:51 ` Dr. David Alan Gilbert
1 sibling, 0 replies; 94+ messages in thread
From: Igor Mammedov @ 2020-05-14 9:47 UTC (permalink / raw)
To: Jag Raman
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
kraxel, quintela, mst, armbru, kanth.ghatraju, felipe, thuth,
ehabkost, konrad.wilk, dgilbert, liran.alon, Stefan Hajnoczi,
pbonzini, rth, kwolf, Daniel Berrange, mreitz, ross.lagerwall,
marcandre.lureau, thanos.makatos
On Wed, 13 May 2020 16:08:06 -0400
Jag Raman <jag.raman@oracle.com> wrote:
> > On May 13, 2020, at 11:25 AM, Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > On Wed, 13 May 2020 09:40:42 +0100
> > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> >> On Tue, May 12, 2020 at 07:56:33AM -0400, Jag Raman wrote:
> >>>
> >>>
> >>>> On May 12, 2020, at 4:48 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>>>
> >>>> On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
> >>>>> From: Jagannathan Raman <jag.raman@oracle.com>
> >>>>>
> >>>>> Allow RAM MemoryRegion to be created from an offset in a file, instead
> >>>>> of allocating at offset of 0 by default. This is needed to synchronize
> >>>>> RAM between QEMU & remote process.
> >>>>
> >>>> Can you elaborate on why remote processes require the RAM to be offset
> >>>> from zero ?
> >>>
> >>> Hi Daniel,
> >>>
> >>> As it turns out, the RAM is scattered across the physical address space
> >>> (system_memory) of QEMU. Therefore, the system memory is composed
> >>> of multiple sections of RAM, and some sections start at a non-zero RAM
> >>> offset.
> >>>
> >>> As a result, the remote process needs the ability to map these RAM
> >>> sections into system_memory.
> >>
> >> To explain a bit more, my understanding is that the offset is
> >> specifically for mmap(2). As Jag alluded to, multiple sections can use a
> >> single backing RAM file. These sections have different offsets in the
> >> file.
> >>
> >> Jag, maybe you can include a concrete explanation like the following in
> >> the commit description:
> >>
> >> Launch QEMU like this:
> >>
> >> qemu-system-x86_64 -mem-path /dev/shm -m 8G
> >>
> >> There is only one RAM file descriptor:
> >>
> >> $ cat /proc/$(pidof qemu)/fd
> >> ...
> >> lrwx------. 1 stefanha stefanha 64 May 13 09:34 19 -> '/dev/shm/qemu_back_mem.pc.ram.7YAlqn (deleted)'
> >>
> >> But the memory tree shows that single file is split into multiple ranges
> >> of guest physical address space:
> >>
> >> (qemu) info mtree
> >> memory-region: system
> >> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
> >> 0000000000000000-00000000bfffffff (prio 0, i/o): alias ram-below-4g @pc.ram 0000000000000000-00000000bfffffff
> >> ...
> >> 0000000100000000-000000023fffffff (prio 0, i/o): alias ram-above-4g @pc.ram 00000000c0000000-00000001ffffffff
> >>
> >> This means QEMU needs to send two regions to the remote device process.
> >> They both mmap the same file but from different starting file offsets.
> >
> > are we talking here about GPA offests her or about host offsets in mmaped host file?
> > If it's the later then above mtree doesn't show true picture (those entries are just aliases),
> > main guest RAM is allocated as a single continuous chunk (so far) which belongs
> > to a memory-backend.
>
> Thanks for the info about ‘mtree’ QMP option. We’ll use that to better explain the need for offset
> during memory allocation.
>
> As we can observe from the ‘mtree’ output, different sections of system memory vector into the
> RAM. Since we have only one file descriptor available for all of RAM, we need to mmap() these
> sections at different offsets within the memory file.
>
> Hey Igor, the offset passed into the mmap() syscall is the offset within host file. Thanks for
> pointing out that these are aliases. I believe the mmap() operation is equivalent to the “alias”
> operation within MemoryRegion framework. We are sending the ‘fd’, ‘offset’ within the fd and
> the size of these RAM regions to the remote device over the unix socket. Hopefully, this looks
> good to you.
could you point to a specific patch where on remote device that is being received and used?
>
> Thanks!
> --
> Jag
>
> >
> >> Stefan
> >
> >
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset
2020-05-13 20:08 ` Jag Raman
2020-05-14 9:47 ` Igor Mammedov
@ 2020-05-14 9:51 ` Dr. David Alan Gilbert
1 sibling, 0 replies; 94+ messages in thread
From: Dr. David Alan Gilbert @ 2020-05-14 9:51 UTC (permalink / raw)
To: Jag Raman
Cc: Elena Ufimtseva, fam, Swapnil Ingle, John G Johnson, qemu-devel,
pbonzini, kraxel, quintela, mst, armbru, kanth.ghatraju, felipe,
thuth, ehabkost, konrad.wilk, liran.alon, Stefan Hajnoczi,
Igor Mammedov, rth, kwolf, Daniel Berrange, mreitz,
ross.lagerwall, marcandre.lureau, thanos.makatos
* Jag Raman (jag.raman@oracle.com) wrote:
>
>
> > On May 13, 2020, at 11:25 AM, Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > On Wed, 13 May 2020 09:40:42 +0100
> > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> >> On Tue, May 12, 2020 at 07:56:33AM -0400, Jag Raman wrote:
> >>>
> >>>
> >>>> On May 12, 2020, at 4:48 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>>>
> >>>> On Wed, Apr 22, 2020 at 09:13:36PM -0700, elena.ufimtseva@oracle.com wrote:
> >>>>> From: Jagannathan Raman <jag.raman@oracle.com>
> >>>>>
> >>>>> Allow RAM MemoryRegion to be created from an offset in a file, instead
> >>>>> of allocating at offset of 0 by default. This is needed to synchronize
> >>>>> RAM between QEMU & remote process.
> >>>>
> >>>> Can you elaborate on why remote processes require the RAM to be offset
> >>>> from zero ?
> >>>
> >>> Hi Daniel,
> >>>
> >>> As it turns out, the RAM is scattered across the physical address space
> >>> (system_memory) of QEMU. Therefore, the system memory is composed
> >>> of multiple sections of RAM, and some sections start at a non-zero RAM
> >>> offset.
> >>>
> >>> As a result, the remote process needs the ability to map these RAM
> >>> sections into system_memory.
> >>
> >> To explain a bit more, my understanding is that the offset is
> >> specifically for mmap(2). As Jag alluded to, multiple sections can use a
> >> single backing RAM file. These sections have different offsets in the
> >> file.
> >>
> >> Jag, maybe you can include a concrete explanation like the following in
> >> the commit description:
> >>
> >> Launch QEMU like this:
> >>
> >> qemu-system-x86_64 -mem-path /dev/shm -m 8G
> >>
> >> There is only one RAM file descriptor:
> >>
> >> $ cat /proc/$(pidof qemu)/fd
> >> ...
> >> lrwx------. 1 stefanha stefanha 64 May 13 09:34 19 -> '/dev/shm/qemu_back_mem.pc.ram.7YAlqn (deleted)'
> >>
> >> But the memory tree shows that single file is split into multiple ranges
> >> of guest physical address space:
> >>
> >> (qemu) info mtree
> >> memory-region: system
> >> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
> >> 0000000000000000-00000000bfffffff (prio 0, i/o): alias ram-below-4g @pc.ram 0000000000000000-00000000bfffffff
> >> ...
> >> 0000000100000000-000000023fffffff (prio 0, i/o): alias ram-above-4g @pc.ram 00000000c0000000-00000001ffffffff
> >>
> >> This means QEMU needs to send two regions to the remote device process.
> >> They both mmap the same file but from different starting file offsets.
> >
> > are we talking here about GPA offests her or about host offsets in mmaped host file?
> > If it's the later then above mtree doesn't show true picture (those entries are just aliases),
> > main guest RAM is allocated as a single continuous chunk (so far) which belongs
> > to a memory-backend.
>
> Thanks for the info about ‘mtree’ QMP option. We’ll use that to better explain the need for offset
> during memory allocation.
>
> As we can observe from the ‘mtree’ output, different sections of system memory vector into the
> RAM. Since we have only one file descriptor available for all of RAM, we need to mmap() these
> sections at different offsets within the memory file.
>
> Hey Igor, the offset passed into the mmap() syscall is the offset within host file. Thanks for
> pointing out that these are aliases. I believe the mmap() operation is equivalent to the “alias”
> operation within MemoryRegion framework. We are sending the ‘fd’, ‘offset’ within the fd and
> the size of these RAM regions to the remote device over the unix socket. Hopefully, this looks
> good to you.
Vhost-user already does something similar; see it's
vhost_user_fill_set_mem_table_msg:
msg->payload.memory.regions[*fd_num].userspace_addr =
reg->userspace_addr;
msg->payload.memory.regions[*fd_num].memory_size =
reg->memory_size;
msg->payload.memory.regions[*fd_num].guest_phys_addr =
reg->guest_phys_addr;
msg->payload.memory.regions[*fd_num].mmap_offset = offset;
Note you're not needing to map the fd with an offset on the qemu side,
it's something only needed on the remote.
Dave
> Thanks!
> --
> Jag
>
> >
> >> Stefan
> >
> >
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2020-05-14 9:52 UTC | newest]
Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-23 4:13 [PATCH RESEND v6 00/36] Initial support for multi-process qemu elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 01/36] memory: alloc RAM from file at offset elena.ufimtseva
2020-05-12 8:26 ` Stefan Hajnoczi
2020-05-12 8:48 ` Daniel P. Berrangé
2020-05-12 11:56 ` Jag Raman
2020-05-13 8:40 ` Stefan Hajnoczi
2020-05-13 15:25 ` Igor Mammedov
2020-05-13 20:08 ` Jag Raman
2020-05-14 9:47 ` Igor Mammedov
2020-05-14 9:51 ` Dr. David Alan Gilbert
2020-04-23 4:13 ` [PATCH RESEND v6 02/36] multi-process: Refactor machine_init and exit notifiers elena.ufimtseva
2020-04-23 14:13 ` Philippe Mathieu-Daudé
2020-04-23 4:13 ` [PATCH RESEND v6 03/36] command-line: refractor parser code elena.ufimtseva
2020-04-24 12:55 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 04/36] multi-process: Refactor chardev functions out of vl.c elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 05/36] multi-process: Refactor monitor " elena.ufimtseva
2020-04-24 13:02 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 06/36] monitor: destaticize HMP commands elena.ufimtseva
2020-04-23 14:14 ` Philippe Mathieu-Daudé
2020-04-23 15:07 ` Jag Raman
2020-04-23 15:58 ` Philippe Mathieu-Daudé
2020-04-23 4:13 ` [PATCH RESEND v6 07/36] multi-process: add a command line option for debug file elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 08/36] multi-process: Add stub functions to facilitate build of multi-process elena.ufimtseva
2020-04-24 13:12 ` Stefan Hajnoczi
2020-04-24 13:47 ` Jag Raman
2020-04-28 16:29 ` Stefan Hajnoczi
2020-04-28 18:58 ` Jag Raman
2020-04-29 9:41 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 09/36] multi-process: Add config option for multi-process QEMU elena.ufimtseva
2020-04-24 13:47 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 10/36] multi-process: build system for remote device process elena.ufimtseva
2020-04-24 15:04 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 11/36] multi-process: define mpqemu-link object elena.ufimtseva
2020-05-12 8:56 ` Stefan Hajnoczi
2020-05-12 12:09 ` Jag Raman
2020-04-23 4:13 ` [PATCH RESEND v6 12/36] multi-process: add functions to synchronize proxy and remote endpoints elena.ufimtseva
2020-05-12 10:21 ` Stefan Hajnoczi
2020-05-12 12:28 ` Jag Raman
2020-05-13 8:43 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 13/36] multi-process: setup PCI host bridge for remote device elena.ufimtseva
2020-05-12 10:31 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 14/36] multi-process: setup a machine object for remote device process elena.ufimtseva
2020-05-12 10:43 ` Stefan Hajnoczi
2020-05-12 12:12 ` Jag Raman
2020-04-23 4:13 ` [PATCH RESEND v6 15/36] multi-process: setup memory manager for remote device elena.ufimtseva
2020-05-12 12:11 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 16/36] multi-process: remote process initialization elena.ufimtseva
2020-04-23 4:13 ` [PATCH RESEND v6 17/36] multi-process: introduce proxy object elena.ufimtseva
2020-05-12 12:23 ` Stefan Hajnoczi
2020-05-12 12:35 ` Jag Raman
2020-04-23 4:13 ` [PATCH RESEND v6 18/36] multi-process: Initialize Proxy Object's communication channel elena.ufimtseva
2020-05-12 12:35 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 19/36] multi-process: Connect Proxy Object with device in the remote process elena.ufimtseva
2020-05-12 12:54 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 20/36] multi-process: Forward PCI config space acceses to " elena.ufimtseva
2020-05-12 13:50 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 21/36] multi-process: PCI BAR read/write handling for proxy & remote endpoints elena.ufimtseva
2020-05-12 14:19 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 22/36] multi-process: Synchronize remote memory elena.ufimtseva
2020-05-12 15:07 ` Stefan Hajnoczi
2020-05-12 15:49 ` Dr. David Alan Gilbert
2020-04-23 4:13 ` [PATCH RESEND v6 23/36] multi-process: create IOHUB object to handle irq elena.ufimtseva
2020-05-12 15:57 ` Stefan Hajnoczi
2020-05-12 16:12 ` Stefan Hajnoczi
2020-04-23 4:13 ` [PATCH RESEND v6 24/36] multi-process: Retrieve PCI info from remote process elena.ufimtseva
2020-05-12 16:07 ` Stefan Hajnoczi
2020-04-23 4:14 ` [PATCH RESEND v6 25/36] multi-process: Introduce build flags to separate remote process code elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 26/36] multi-process: add parse_cmdline in remote process elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 27/36] multi-process: add support to parse device option elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 28/36] multi-process: send heartbeat messages to remote elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 29/36] multi-process: handle heartbeat messages in remote process elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 30/36] multi-process: perform device reset in the " elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 31/36] multi-process/mon: choose HMP commands based on target elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 32/36] multi-process/mon: stub functions to enable QMP module for remote process elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 33/36] multi-process/mon: enable QMP module support in the " elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 34/36] multi-process/mon: Initialize QMP module for remote processes elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 35/36] multi-process: add the concept description to docs/devel/qemu-multiprocess elena.ufimtseva
2020-04-23 4:14 ` [PATCH RESEND v6 36/36] multi-process: add configure and usage information elena.ufimtseva
2020-04-23 13:54 ` 罗勇刚(Yonggang Luo)
2020-04-23 15:01 ` Jag Raman
2020-04-23 22:56 ` 罗勇刚(Yonggang Luo)
2020-04-24 0:34 ` 罗勇刚(Yonggang Luo)
2020-04-24 12:48 ` [PATCH RESEND v6 00/36] Initial support for multi-process qemu Stefan Hajnoczi
2020-04-24 12:53 ` Daniel P. Berrangé
2020-04-24 12:53 ` Eric Blake
2020-04-24 13:42 ` Max Reitz
2020-04-28 17:29 ` Stefan Hajnoczi
2020-04-28 17:47 ` Michael S. Tsirkin
2020-04-29 9:30 ` Stefan Hajnoczi
2020-04-29 9:59 ` Michael S. Tsirkin
2020-05-11 14:40 ` Stefan Hajnoczi
2020-05-11 19:30 ` Jag Raman
2020-05-12 16:13 ` Stefan Hajnoczi
2020-05-12 16:55 ` Jag Raman
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.