From: Stefan Hajnoczi <stefanha@gmail.com>
To: Jagannathan Raman <jag.raman@oracle.com>
Cc: elena.ufimtseva@oracle.com, fam@euphon.net,
john.g.johnson@oracle.com, qemu-devel@nongnu.org,
kraxel@redhat.com, quintela@redhat.com, mst@redhat.com,
armbru@redhat.com, kanth.ghatraju@oracle.com, thuth@redhat.com,
ehabkost@redhat.com, konrad.wilk@oracle.com, dgilbert@redhat.com,
liran.alon@oracle.com, stefanha@redhat.com, rth@twiddle.net,
kwolf@redhat.com, berrange@redhat.com, mreitz@redhat.com,
ross.lagerwall@citrix.com, marcandre.lureau@gmail.com,
pbonzini@redhat.com
Subject: Re: [RFC v4 PATCH 20/49] multi-process: add qdev_proxy_add to create proxy devices
Date: Thu, 21 Nov 2019 12:16:47 +0000 [thread overview]
Message-ID: <20191121121647.GO439743@stefanha-x1.localdomain> (raw)
In-Reply-To: <36de8c87e14b6623fd1a570c0c34dd0667ba8aec.1571905346.git.jag.raman@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 4364 bytes --]
On Thu, Oct 24, 2019 at 05:09:01AM -0400, Jagannathan Raman wrote:
> diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
> index 3b84055..fc1c731 100644
> --- a/hw/proxy/qemu-proxy.c
> +++ b/hw/proxy/qemu-proxy.c
> @@ -337,7 +337,8 @@ static void init_proxy(PCIDevice *dev, char *command, bool need_spawn, Error **e
>
> if (!pdev->managed) {
> if (need_spawn) {
> - if (!remote_spawn(pdev, command, &local_error)) {
> + if (remote_spawn(pdev, command, &local_error)) {
> + fprintf(stderr, "remote spawn failed\n");
> return;
> }
> }
Looks like a fix for a bug in a previous patch. Please squash it.
Also, please propagate local_err and do not use fprintf in a function
that has an errp argument for reporting errors.
> +#if defined(CONFIG_MPQEMU)
Maybe these functions should be in a separate file that the makefile
includes when CONFIG_MPQEMU is defined.
> +
> +static PCIProxyDev *get_proxy_object_rid(const char *rid)
> +{
> + PCIProxyDev *entry;
> + if (!proxy_list_lock.initialized) {
> + QLIST_INIT(&proxy_dev_list.devices);
> + qemu_mutex_init(&proxy_list_lock);
> + }
This locking approach is broken since exactly-once initialization
semantics are required to avoid races during initialization. Is the
lock needed at all?
> +DeviceState *qdev_remote_add(QemuOpts *opts, bool device, Error **errp)
> +{
> + PCIProxyDev *pdev = NULL;
> + DeviceState *dev;
> + const char *rid, *rsocket = NULL, *command = NULL;
> + QDict *qdict_new;
> + const char *id = NULL;
> + const char *driver = NULL;
> + const char *bus = NULL;
> +
> + if (!proxy_list_lock.initialized) {
> + QLIST_INIT(&proxy_dev_list.devices);
> + qemu_mutex_init(&proxy_list_lock);
> + }
> +
> + rid = qemu_opt_get(opts, "rid");
> + if (!rid) {
> + error_setg(errp, "rdevice option needs rid specified.");
> + return NULL;
> + }
> + if (device) {
> + driver = qemu_opt_get(opts, "driver");
> + /* TODO: properly identify the device class. */
> + if (strncmp(driver, "lsi", 3) == 0) {
> + id = qemu_opts_id(opts);
> + if (!id) {
> + error_setg(errp, "qdev_remote_add option needs id specified.");
> + return NULL;
> + }
> + }
> + }
> +
> + rsocket = qemu_opt_get(opts, "socket");
> + if (rsocket) {
> + if (strlen(rsocket) > MAX_RID_LENGTH) {
> + error_setg(errp, "Socket number is incorrect.");
> + return NULL;
> + }
> + }
> + /*
> + * TODO: verify command with known commands and on remote end.
> + * How else can we verify the binary we launch without libvirtd support?
> + */
> + command = qemu_opt_get(opts, "command");
> + if (!rsocket && !command) {
> + error_setg(errp, "rdevice option needs socket or command specified.");
> + return NULL;
> + }
> +
> + bus = qemu_opt_get(opts, "bus");
> + dev = qdev_proxy_add(rid, id, (char *)bus, (char *)command,
> + rsocket ? atoi(rsocket) : -1,
> + rsocket ? true : false, errp);
> + if (!dev) {
> + error_setg(errp, "qdev_proxy_add error.");
> + return NULL;
> + }
> +
> + qdict_new = qemu_opts_to_qdict(opts, NULL);
> +
> + if (!qdict_new) {
> + error_setg(errp, "Could not parse rdevice options.");
> + return NULL;
> + }
> +
> + pdev = PCI_PROXY_DEV(dev);
> + if (!pdev->set_remote_opts) {
> + /* TODO: destroy proxy? */
> + error_setg(errp, "set_remote_opts failed.");
> + return NULL;
> + } else {
> + if (id && !pdev->dev_id) {
> + pdev->dev_id = g_strdup(id);
> + }
> + pdev->set_remote_opts(PCI_DEVICE(pdev), qdict_new,
> + device ? DEV_OPTS : DRIVE_OPTS);
This function needs to be able to return an error if setting the options
failed. A response message needs to be defined in the protocol to
support this.
Is DRIVE_OPTS still needed? I thought the drives would be configured in
the remote process and no proxy objects were needed on the QEMU side?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-11-21 12:18 UTC|newest]
Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 9:08 [RFC v4 PATCH 00/49] Initial support of multi-process qemu Jagannathan Raman
2019-10-24 9:08 ` [RFC v4 PATCH 01/49] multi-process: memory: alloc RAM from file at offset Jagannathan Raman
2019-10-24 9:08 ` [RFC v4 PATCH 02/49] multi-process: util: Add qemu_thread_cancel() to cancel running thread Jagannathan Raman
2019-11-13 15:30 ` Stefan Hajnoczi
2019-11-13 15:38 ` Jag Raman
2019-11-13 15:51 ` Daniel P. Berrangé
2019-11-13 16:04 ` Jag Raman
2019-11-13 16:35 ` Daniel P. Berrangé
2019-10-24 9:08 ` [RFC v4 PATCH 03/49] multi-process: add a command line option for debug file Jagannathan Raman
2019-11-13 15:35 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 04/49] multi-process: Add stub functions to facilate build of multi-process Jagannathan Raman
2019-10-24 9:08 ` [RFC v4 PATCH 05/49] multi-process: Add config option for multi-process QEMU Jagannathan Raman
2019-10-24 9:08 ` [RFC v4 PATCH 06/49] multi-process: build system for remote device process Jagannathan Raman
2019-10-24 9:08 ` [RFC v4 PATCH 07/49] multi-process: define mpqemu-link object Jagannathan Raman
2019-11-11 16:41 ` Stefan Hajnoczi
2019-11-13 15:47 ` Jag Raman
2019-11-13 15:53 ` Stefan Hajnoczi
2019-11-18 15:26 ` Jag Raman
2019-10-24 9:08 ` [RFC v4 PATCH 08/49] multi-process: add functions to synchronize proxy and remote endpoints Jagannathan Raman
2019-10-24 9:08 ` [RFC v4 PATCH 09/49] multi-process: setup PCI host bridge for remote device Jagannathan Raman
2019-11-13 16:07 ` Stefan Hajnoczi
2019-11-18 15:25 ` Jag Raman
2019-11-21 10:37 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 10/49] multi-process: setup a machine object for remote device process Jagannathan Raman
2019-11-13 16:22 ` Stefan Hajnoczi
2019-11-18 15:29 ` Jag Raman
2019-10-24 9:08 ` [RFC v4 PATCH 11/49] multi-process: setup memory manager for remote device Jagannathan Raman
2019-11-13 16:33 ` Stefan Hajnoczi
2019-11-13 16:34 ` Jag Raman
2019-10-24 9:08 ` [RFC v4 PATCH 12/49] multi-process: remote process initialization Jagannathan Raman
2019-11-13 16:38 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 13/49] multi-process: introduce proxy object Jagannathan Raman
2019-11-21 11:09 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 14/49] mutli-process: build remote command line args Jagannathan Raman
2019-11-21 11:23 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 15/49] multi-process: PCI BAR read/write handling for proxy & remote endpoints Jagannathan Raman
2019-11-21 11:33 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 16/49] multi-process: Add LSI device proxy object Jagannathan Raman
2019-11-21 11:35 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 17/49] multi-process: Synchronize remote memory Jagannathan Raman
2019-11-21 11:44 ` Stefan Hajnoczi
2019-10-24 9:08 ` [RFC v4 PATCH 18/49] multi-process: create IOHUB object to handle irq Jagannathan Raman
2019-11-21 12:02 ` Stefan Hajnoczi
2019-10-24 9:09 ` [RFC v4 PATCH 19/49] multi-process: configure remote side devices Jagannathan Raman
2019-11-21 12:05 ` Stefan Hajnoczi
2019-10-24 9:09 ` [RFC v4 PATCH 20/49] multi-process: add qdev_proxy_add to create proxy devices Jagannathan Raman
2019-11-21 12:16 ` Stefan Hajnoczi [this message]
2019-10-24 9:09 ` [RFC v4 PATCH 21/49] multi-process: remote: add setup_devices and setup_drive msg processing Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 22/49] multi-process: remote: use fd for socket from parent process Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 23/49] multi-process: remote: add create_done condition Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 24/49] multi-process: add processing of remote drive and device command line Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 25/49] multi-process: Introduce build flags to separate remote process code Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 26/49] multi-process: refractor vl.c code to re-use in remote Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 27/49] multi-process: add remote option Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 28/49] multi-process: add remote options parser Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 29/49] multi-process: add parse_cmdline in remote process Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 30/49] multi-process: send heartbeat messages to remote Jagannathan Raman
2019-11-11 16:27 ` Stefan Hajnoczi
2019-11-13 16:01 ` Jag Raman
2019-11-21 12:19 ` Stefan Hajnoczi
2019-10-24 9:09 ` [RFC v4 PATCH 31/49] multi-process: handle heartbeat messages in remote process Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 32/49] multi-process: Use separate MMIO communication channel Jagannathan Raman
2019-11-11 16:21 ` Stefan Hajnoczi
2019-11-13 16:14 ` Jag Raman
2019-11-21 12:31 ` Stefan Hajnoczi
2019-10-24 9:09 ` [RFC v4 PATCH 33/49] multi-process: perform device reset in the remote process Jagannathan Raman
2019-11-11 16:19 ` Stefan Hajnoczi
2019-11-13 16:15 ` Jag Raman
2019-10-24 9:09 ` [RFC v4 PATCH 34/49] multi-process/mon: choose HMP commands based on target Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 35/49] multi-process/mon: stub functions to enable QMP module for remote process Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 36/49] multi-process/mon: enable QMP module support in the " Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 37/49] multi-process/mon: Refactor monitor/chardev functions out of vl.c Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 38/49] multi-process/mon: Initialize QMP module for remote processes Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 39/49] multi-process: prevent duplicate memory initialization in remote Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 40/49] multi-process/mig: build migration module in the remote process Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 41/49] multi-process/mig: Enable VMSD save in the Proxy object Jagannathan Raman
2019-11-13 15:50 ` Daniel P. Berrangé
2019-11-13 16:32 ` Jag Raman
2019-11-13 17:11 ` Daniel P. Berrangé
2019-11-18 15:42 ` Jag Raman
2019-11-22 10:34 ` Dr. David Alan Gilbert
2019-10-24 9:09 ` [RFC v4 PATCH 42/49] multi-process/mig: Send VMSD of remote to " Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 43/49] multi-process/mig: Load VMSD in the proxy object Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 44/49] multi-process/mig: refactor runstate_check into common file Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 45/49] multi-process/mig: Synchronize runstate of remote process Jagannathan Raman
2019-11-11 16:17 ` Stefan Hajnoczi
2019-11-13 16:33 ` Jag Raman
2019-10-24 9:09 ` [RFC v4 PATCH 46/49] multi-process/mig: Restore the VMSD in " Jagannathan Raman
2019-10-24 9:09 ` [RFC v4 PATCH 47/49] multi-process: Enable support for multiple devices in remote Jagannathan Raman
2019-11-11 16:15 ` Stefan Hajnoczi
2019-11-13 16:21 ` Jag Raman
2019-10-24 9:09 ` [RFC v4 PATCH 48/49] multi-process: add the concept description to docs/devel/qemu-multiprocess Jagannathan Raman
2019-10-25 19:33 ` Elena Ufimtseva
2019-11-07 15:50 ` Stefan Hajnoczi
2019-11-11 15:41 ` Stefan Hajnoczi
2019-10-24 9:09 ` [RFC v4 PATCH 49/49] multi-process: add configure and usage information Jagannathan Raman
2019-11-07 14:02 ` Stefan Hajnoczi
2019-11-07 14:33 ` Michael S. Tsirkin
2019-11-08 11:17 ` Stefan Hajnoczi
2019-11-08 11:32 ` Daniel P. Berrangé
2019-11-07 14:39 ` Daniel P. Berrangé
2019-11-07 15:53 ` Jag Raman
2019-11-08 11:14 ` Stefan Hajnoczi
2019-10-25 2:08 ` [RFC v4 PATCH 00/49] Initial support of multi-process qemu no-reply
2019-10-25 2:08 ` no-reply
2019-10-25 2:10 ` no-reply
2019-11-21 12:46 ` Stefan Hajnoczi
2019-12-10 6:47 ` [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update Elena Ufimtseva
2019-12-13 10:41 ` Stefan Hajnoczi
2019-12-16 19:46 ` Elena Ufimtseva
2019-12-16 19:57 ` Felipe Franciosi
2019-12-17 16:33 ` Stefan Hajnoczi
2019-12-17 22:57 ` Felipe Franciosi
2019-12-18 0:00 ` Paolo Bonzini
2019-12-19 13:36 ` Stefan Hajnoczi
2019-12-20 17:15 ` John G Johnson
2020-01-02 10:00 ` Stefan Hajnoczi
2020-01-02 10:04 ` Stefan Hajnoczi
2019-12-19 11:55 ` Stefan Hajnoczi
2019-12-19 12:33 ` Felipe Franciosi
2019-12-19 12:55 ` Daniel P. Berrangé
2019-12-20 9:47 ` Stefan Hajnoczi
2019-12-20 9:50 ` Paolo Bonzini
2019-12-20 14:14 ` Felipe Franciosi
2019-12-20 15:25 ` Alex Williamson
2019-12-20 16:00 ` Felipe Franciosi
2020-02-25 9:16 ` Thanos Makatos
2019-12-20 10:22 ` Daniel P. Berrangé
2020-01-02 10:42 ` Stefan Hajnoczi
2020-01-02 11:03 ` Felipe Franciosi
2020-01-02 18:55 ` Marc-André Lureau
2020-01-08 16:31 ` Stefan Hajnoczi
2020-01-03 15:59 ` Stefan Hajnoczi
2020-01-14 1:56 ` John G Johnson
2020-01-17 17:25 ` Dr. David Alan Gilbert
2019-12-19 16:40 ` Jag Raman
2019-12-19 12:50 ` Daniel P. Berrangé
2019-12-19 16:46 ` Daniel P. Berrangé
2020-01-02 16:01 ` Elena Ufimtseva
2020-01-03 15:00 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191121121647.GO439743@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=elena.ufimtseva@oracle.com \
--cc=fam@euphon.net \
--cc=jag.raman@oracle.com \
--cc=john.g.johnson@oracle.com \
--cc=kanth.ghatraju@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=liran.alon@oracle.com \
--cc=marcandre.lureau@gmail.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=ross.lagerwall@citrix.com \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).