From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Jagannathan Raman <jag.raman@oracle.com>, qemu-devel@nongnu.org
Cc: elena.ufimtseva@oracle.com, fam@euphon.net,
swapnil.ingle@nutanix.com, john.g.johnson@oracle.com,
kraxel@redhat.com, quintela@redhat.com, mst@redhat.com,
armbru@redhat.com, kanth.ghatraju@oracle.com, felipe@nutanix.com,
thuth@redhat.com, ehabkost@redhat.com, konrad.wilk@oracle.com,
dgilbert@redhat.com, alex.williamson@redhat.com,
stefanha@redhat.com, pbonzini@redhat.com, rth@twiddle.net,
kwolf@redhat.com, berrange@redhat.com, mreitz@redhat.com,
ross.lagerwall@citrix.com, marcandre.lureau@gmail.com,
thanos.makatos@nutanix.com
Subject: Re: [PATCH v11 12/19] multi-process: Forward PCI config space acceses to the remote process
Date: Fri, 23 Oct 2020 18:59:27 +0200 [thread overview]
Message-ID: <47f25366-4cf3-7167-d199-1b82d7fd1ec2@redhat.com> (raw)
In-Reply-To: <1a1490ba03686fe29a0f627bec1556a0051fed18.1602784930.git.jag.raman@oracle.com>
On 10/15/20 8:05 PM, Jagannathan Raman wrote:
> 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
>
> TODO:
> Investigate if the local PCI config writes can be dropped.
> Without the proxy local PCI config space writes for the device,
> the driver in the guest times out on the probing.
> We have tried to only refer to the remote for the PCI config writes,
> but the driver timeout in the guest forced as to left this
> as it is (removing local PCI config only).
I expect this TODO to be lost in git history. Better to
commit it in the code and remove it once resolved IMHO.
>
> 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>
> ---
> hw/i386/remote-msg.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++
> hw/pci/proxy.c | 50 ++++++++++++++++++++++++++++++++++++++
> include/io/mpqemu-link.h | 9 +++++++
> io/mpqemu-link.c | 6 +++++
> 4 files changed, 127 insertions(+)
Please have a look at scripts/git.orderfile, it helps
reviewers to avoid scrolling down/up the patches.
>
> diff --git a/hw/i386/remote-msg.c b/hw/i386/remote-msg.c
> index 6451b77..94937db 100644
> --- a/hw/i386/remote-msg.c
> +++ b/hw/i386/remote-msg.c
> @@ -15,6 +15,12 @@
> #include "io/mpqemu-link.h"
> #include "qapi/error.h"
> #include "sysemu/runstate.h"
> +#include "hw/pci/pci.h"
> +
> +static void process_config_write(QIOChannel *ioc, PCIDevice *dev,
> + MPQemuMsg *msg);
> +static void process_config_read(QIOChannel *ioc, PCIDevice *dev,
> + MPQemuMsg *msg);
>
> void coroutine_fn mpqemu_remote_msg_loop_co(void *data)
> {
> @@ -43,6 +49,12 @@ void coroutine_fn mpqemu_remote_msg_loop_co(void *data)
> }
>
> switch (msg.cmd) {
> + case PCI_CONFIG_WRITE:
> + process_config_write(com->ioc, pci_dev, &msg);
> + break;
> + case PCI_CONFIG_READ:
> + process_config_read(com->ioc, pci_dev, &msg);
> + break;
> default:
> error_setg(&local_err,
> "Unknown command (%d) received for device %s (pid=%d)",
> @@ -60,3 +72,53 @@ void coroutine_fn mpqemu_remote_msg_loop_co(void *data)
>
> return;
> }
> +
> +static void process_config_write(QIOChannel *ioc, PCIDevice *dev,
> + MPQemuMsg *msg)
> +{
> + ConfDataMsg *conf = (ConfDataMsg *)&msg->data.conf_data;
> + MPQemuMsg ret = { 0 };
> + Error *local_err = NULL;
> +
> + if ((conf->addr + sizeof(conf->val)) > pci_config_size(dev)) {
> + error_report("Bad address received when writing PCI config, pid %d",
> + getpid());
> + ret.data.u64 = UINT64_MAX;
> + } else {
> + pci_default_write_config(dev, conf->addr, conf->val, conf->l);
> + }
> +
> + ret.cmd = RET_MSG;
> + ret.size = sizeof(ret.data.u64);
> +
> + mpqemu_msg_send(&ret, ioc, &local_err);
> + if (local_err) {
> + error_report("Could not send message to proxy from pid %d",
> + getpid());
> + }
> +}
> +
> +static void process_config_read(QIOChannel *ioc, PCIDevice *dev,
> + MPQemuMsg *msg)
> +{
> + ConfDataMsg *conf = (ConfDataMsg *)&msg->data.conf_data;
> + MPQemuMsg ret = { 0 };
> + Error *local_err = NULL;
> +
> + if ((conf->addr + sizeof(conf->val)) > pci_config_size(dev)) {
> + error_report("Bad address received when reading PCI config, pid %d",
> + getpid());
> + ret.data.u64 = UINT64_MAX;
> + } else {
> + ret.data.u64 = pci_default_read_config(dev, conf->addr, conf->l);
Isn't it endianess issue here? It might makes sense to
declare ConfDataMsg and PCI_CONFIG_READ/PCI_CONFIG_WRITE
packets in little endian.
> + }
> +
> + ret.cmd = RET_MSG;
> + ret.size = sizeof(ret.data.u64);
> +
> + mpqemu_msg_send(&ret, ioc, &local_err);
> + if (local_err) {
> + error_report("Could not send message to proxy from pid %d",
> + getpid());
> + }
> +}
> diff --git a/hw/pci/proxy.c b/hw/pci/proxy.c
> index 7a12f23..27714fe 100644
> --- a/hw/pci/proxy.c
> +++ b/hw/pci/proxy.c
> @@ -16,6 +16,8 @@
> #include "hw/qdev-properties.h"
> #include "monitor/monitor.h"
> #include "migration/blocker.h"
> +#include "io/mpqemu-link.h"
> +#include "qemu/error-report.h"
>
> static void proxy_set_socket(PCIProxyDev *pdev, int fd, Error **errp)
> {
> @@ -69,6 +71,51 @@ static void pci_proxy_dev_exit(PCIDevice *pdev)
> error_free(dev->migration_blocker);
> }
>
> +static int config_op_send(PCIProxyDev *pdev, uint32_t addr, uint32_t *val,
> + int l, unsigned int op)
> +{
> + MPQemuMsg msg = { 0 };
> + uint64_t ret = -EINVAL;
> + Error *local_err = NULL;
> +
> + msg.cmd = op;
> + msg.data.conf_data.addr = addr;
> + msg.data.conf_data.val = (op == PCI_CONFIG_WRITE) ? *val : 0;
> + msg.data.conf_data.l = l;
> + msg.size = sizeof(ConfDataMsg);
> +
> + ret = mpqemu_msg_send_and_await_reply(&msg, pdev, &local_err);
> + if (local_err) {
> + error_report_err(local_err);
> + }
> + if (op == PCI_CONFIG_READ) {
> + *val = (uint32_t)ret;
> + }
> +
> + return ret;
> +}
> +
> +static uint32_t pci_proxy_read_config(PCIDevice *d, uint32_t addr, int len)
> +{
> + uint32_t val;
> +
> + (void)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)
> +{
> + /*
> + * Some of the functions access the copy of the remote device
> + * PCI config space, therefore maintain it updated.
> + */
> + pci_default_write_config(d, addr, val, l);
> +
> + (void)config_op_send(PCI_PROXY_DEV(d), addr, &val, l, PCI_CONFIG_WRITE);
> +}
> +
> static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
> {
> DeviceClass *dc = DEVICE_CLASS(klass);
> @@ -76,6 +123,9 @@ static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
>
> 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;
> +
> device_class_set_props(dc, proxy_properties);
> }
>
> diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
> index 4bea5da..459d345 100644
> --- a/include/io/mpqemu-link.h
> +++ b/include/io/mpqemu-link.h
> @@ -34,6 +34,8 @@ typedef enum {
> MPQEMU_CMD_INIT,
> SYNC_SYSMEM,
> RET_MSG,
> + PCI_CONFIG_WRITE,
> + PCI_CONFIG_READ,
> MPQEMU_CMD_MAX,
> } MPQemuCmd;
>
> @@ -43,6 +45,12 @@ typedef struct {
> off_t offsets[REMOTE_MAX_FDS];
> } SyncSysmemMsg;
>
> +typedef struct {
> + uint32_t addr;
> + uint32_t val;
> + int l;
> +} ConfDataMsg;
Maybe name this PciConfDataMsg?
> +
> /**
> * MPQemuMsg:
> * @cmd: The remote command
> @@ -60,6 +68,7 @@ typedef struct {
>
> union {
> uint64_t u64;
> + ConfDataMsg conf_data;
> SyncSysmemMsg sync_sysmem;
> } data;
>
> diff --git a/io/mpqemu-link.c b/io/mpqemu-link.c
> index 1339cc7..5ef82da 100644
> --- a/io/mpqemu-link.c
> +++ b/io/mpqemu-link.c
> @@ -278,6 +278,12 @@ bool mpqemu_msg_valid(MPQemuMsg *msg)
> return false;
> }
> break;
> + case PCI_CONFIG_WRITE:
> + case PCI_CONFIG_READ:
> + if (msg->size != sizeof(ConfDataMsg)) {
> + return false;
> + }
> + break;
> default:
> break;
> }
>
next prev parent reply other threads:[~2020-10-23 17:24 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 18:04 [PATCH v11 00/19] Initial support for multi-process Qemu Jagannathan Raman
2020-10-15 18:04 ` [PATCH v11 01/19] memory: alloc RAM from file at offset Jagannathan Raman
2020-10-15 18:04 ` [PATCH v11 02/19] multi-process: Add config option for multi-process QEMU Jagannathan Raman
2020-10-23 16:49 ` Philippe Mathieu-Daudé
2020-10-15 18:04 ` [PATCH v11 03/19] multi-process: setup PCI host bridge for remote device Jagannathan Raman
2020-10-15 18:04 ` [PATCH v11 04/19] multi-process: setup a machine object for remote device process Jagannathan Raman
2020-10-23 16:33 ` Philippe Mathieu-Daudé
2020-10-15 18:04 ` [PATCH v11 05/19] multi-process: add qio channel function to transmit Jagannathan Raman
2020-10-23 16:36 ` Philippe Mathieu-Daudé
2020-12-04 14:39 ` Marc-André Lureau
2020-10-15 18:04 ` [PATCH v11 06/19] multi-process: define MPQemuMsg format and transmission functions Jagannathan Raman
2020-10-23 13:53 ` Stefan Hajnoczi
2020-10-15 18:05 ` [PATCH v11 07/19] multi-process: Initialize message handler in remote device Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 08/19] multi-process: Associate fd of a PCIDevice with its object Jagannathan Raman
2020-10-23 13:55 ` Stefan Hajnoczi
2020-10-15 18:05 ` [PATCH v11 09/19] multi-process: setup memory manager for remote device Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 10/19] multi-process: introduce proxy object Jagannathan Raman
2020-10-23 13:56 ` Stefan Hajnoczi
2020-10-15 18:05 ` [PATCH v11 11/19] multi-process: add proxy communication functions Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 12/19] multi-process: Forward PCI config space acceses to the remote process Jagannathan Raman
2020-10-23 16:59 ` Philippe Mathieu-Daudé [this message]
2020-10-23 17:20 ` Philippe Mathieu-Daudé
2020-10-15 18:05 ` [PATCH v11 13/19] multi-process: PCI BAR read/write handling for proxy & remote endpoints Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 14/19] multi-process: Synchronize remote memory Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 15/19] multi-process: create IOHUB object to handle irq Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 16/19] multi-process: Retrieve PCI info from remote process Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 17/19] multi-process: perform device reset in the " Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 18/19] multi-process: add the concept description to docs/devel/qemu-multiprocess Jagannathan Raman
2020-10-15 18:05 ` [PATCH v11 19/19] multi-process: add configure and usage information Jagannathan Raman
2020-11-04 18:39 ` Philippe Mathieu-Daudé
2020-10-23 13:57 ` [PATCH v11 00/19] Initial support for multi-process Qemu 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=47f25366-4cf3-7167-d199-1b82d7fd1ec2@redhat.com \
--to=philmd@redhat.com \
--cc=alex.williamson@redhat.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=felipe@nutanix.com \
--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=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=swapnil.ingle@nutanix.com \
--cc=thanos.makatos@nutanix.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).