All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Jag Raman <jag.raman@oracle.com>
Cc: elena.ufimtseva@oracle.com, fam@euphon.net,
	swapnil.ingle@nutanix.com, 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,
	felipe@nutanix.com, thuth@redhat.com, ehabkost@redhat.com,
	konrad.wilk@oracle.com, liran.alon@oracle.com,
	stefanha@redhat.com, thanos.makatos@nutanix.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: [PATCH v5 41/50] multi-process/mig: Enable VMSD save in the Proxy object
Date: Thu, 5 Mar 2020 17:04:22 +0000	[thread overview]
Message-ID: <20200305170422.GN3130@work-vm> (raw)
In-Reply-To: <566485f3-bc78-991a-5ff7-b0f99977d0e8@oracle.com>

* Jag Raman (jag.raman@oracle.com) wrote:
> 
> 
> On 3/5/2020 7:31 AM, Dr. David Alan Gilbert wrote:
> > * Jagannathan Raman (jag.raman@oracle.com) wrote:
> > > Collect the VMSD from remote process on the source and save
> > > it to the channel leading to the destination
> > > 
> > > 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>
> > > ---
> > >   v4 -> v5:
> > >    - Using qemu_file_shutdown() instead of qemu_thread_cancel(). Removed patch
> > >      which introduced qemu_thread_cancel()
> > > 
> > >   hw/proxy/qemu-proxy.c         | 135 ++++++++++++++++++++++++++++++++++++++++++
> > >   include/hw/proxy/qemu-proxy.h |   2 +
> > >   include/io/mpqemu-link.h      |   1 +
> > >   3 files changed, 138 insertions(+)
> > > 
> > > diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
> > > index b1b9282..19f0dbb 100644
> > > --- a/hw/proxy/qemu-proxy.c
> > > +++ b/hw/proxy/qemu-proxy.c
> > > @@ -23,6 +23,14 @@
> > >   #include "util/event_notifier-posix.c"
> > >   #include "hw/boards.h"
> > >   #include "include/qemu/log.h"
> > > +#include "io/channel.h"
> > > +#include "migration/qemu-file-types.h"
> > > +#include "qapi/error.h"
> > > +#include "io/channel-util.h"
> > > +#include "migration/qemu-file-channel.h"
> > > +#include "migration/qemu-file.h"
> > > +#include "migration/migration.h"
> > > +#include "migration/vmstate.h"
> > >   QEMUTimer *hb_timer;
> > >   static void pci_proxy_dev_realize(PCIDevice *dev, Error **errp);
> > > @@ -35,6 +43,9 @@ static void broadcast_init(void);
> > >   static int config_op_send(PCIProxyDev *dev, uint32_t addr, uint32_t *val, int l,
> > >                             unsigned int op);
> > > +#define PAGE_SIZE qemu_real_host_page_size
> > > +uint8_t *mig_data;
> > > +
> > >   static void childsig_handler(int sig, siginfo_t *siginfo, void *ctx)
> > >   {
> > >       /* TODO: Add proper handler. */
> > > @@ -460,6 +471,129 @@ static void pci_proxy_dev_inst_init(Object *obj)
> > >       dev->mem_init = false;
> > >   }
> > > +typedef struct {
> > > +    QEMUFile *rem;
> > > +    PCIProxyDev *dev;
> > > +} proxy_mig_data;
> > > +
> > > +static void *proxy_mig_out(void *opaque)
> > > +{
> > > +    proxy_mig_data *data = opaque;
> > > +    PCIProxyDev *dev = data->dev;
> > > +    uint8_t byte;
> > > +    uint64_t data_size = PAGE_SIZE;
> > > +
> > > +    mig_data = g_malloc(data_size);
> > > +
> > > +    while (true) {
> > > +        byte = qemu_get_byte(data->rem);
> > > +
> > > +        if (qemu_file_get_error(data->rem)) {
> > > +            break;
> > > +        }
> > > +
> > > +        mig_data[dev->migsize++] = byte;
> > > +        if (dev->migsize == data_size) {
> > > +            data_size += PAGE_SIZE;
> > > +            mig_data = g_realloc(mig_data, data_size);
> > > +        }
> > > +    }
> > > +
> > > +    return NULL;
> > > +}
> > > +
> > > +static int proxy_pre_save(void *opaque)
> > > +{
> > > +    PCIProxyDev *pdev = opaque;
> > > +    proxy_mig_data *mig_data;
> > > +    QEMUFile *f_remote;
> > > +    MPQemuMsg msg = {0};
> > > +    QemuThread thread;
> > > +    Error *err = NULL;
> > > +    QIOChannel *ioc;
> > > +    uint64_t size;
> > > +    int fd[2];
> > > +
> > > +    if (socketpair(AF_UNIX, SOCK_STREAM, 0, fd)) {
> > > +        return -1;
> > > +    }
> > > +
> > > +    ioc = qio_channel_new_fd(fd[0], &err);
> > > +    if (err) {
> > > +        error_report_err(err);
> > > +        return -1;
> > > +    }
> > > +
> > > +    qio_channel_set_name(QIO_CHANNEL(ioc), "PCIProxyDevice-mig");
> > > +
> > > +    f_remote = qemu_fopen_channel_input(ioc);
> > > +
> > > +    pdev->migsize = 0;
> > > +
> > > +    mig_data = g_malloc0(sizeof(proxy_mig_data));
> > > +    mig_data->rem = f_remote;
> > 
> > This feels way too complicated.   Since we know f_remote is always just
> > a simple fd we're getting we don't need to use qio or qemu_file here;
> > just use the fd - nice and simple.
> > 
> > Then the code to read it can just use read(2) with a sensible size chunk
> > rather than reading a byte at a time.
> 
> Hi Dave,
> 
> Upon closer inspection, we found that the migration code on the remote
> (which uses QEMUFile) could sometimes set an error on the channel using
> qemu_file_set_error(). We needed to use qemu_file_get_error() to catch
> these errors and abort migration. So we had to stick with QEMUFile at
> the receiving end as well.

I realise you need to use a QEMUFile on the part that connects to the
Savevm code/vmstate code - but that doesn't mean you need it on the side
that just connects between your pipe and the qemu.

> > 
> > > +    mig_data->dev = pdev;
> > > +
> > > +    qemu_thread_create(&thread, "Proxy MIG_OUT", proxy_mig_out, mig_data,
> > > +                       QEMU_THREAD_DETACHED);
> > 
> > I'm just checking why a thread is necessary; is this because you need to
> > be able to start reading before you block waiting for the remote to tell
> > you the size - worrying that if you don't start reading then the remote
> > might block waiting for us?
> 
> Yes, Dave. That is correct.
> 
> > 
> > > +    msg.cmd = START_MIG_OUT;
> > > +    msg.bytestream = 0;
> > > +    msg.num_fds = 2;
> > > +    msg.fds[0] = fd[1];
> > > +    msg.fds[1] = GET_REMOTE_WAIT;
> > > +
> > > +    mpqemu_msg_send(&msg, pdev->mpqemu_link->com);
> > > +    size = wait_for_remote(msg.fds[1]);
> > > +    PUT_REMOTE_WAIT(msg.fds[1]);
> > > +
> > > +    assert(size != ULLONG_MAX);
> > > +
> > > +    /*
> > > +     * migsize is being update by a separate thread. Using volatile to
> > > +     * instruct the compiler to fetch the value of this variable from
> > > +     * memory during every read
> > > +     */
> > > +    while (*((volatile uint64_t *)&pdev->migsize) < size) {
> > > +    }
> > 
> > Hmm.  I suggest the following:
> > 
> >    a) You create a shared 'size' variable;  and initialize it to
> >      UINT64_MAX.
> >    b) The thread uses atomic_read(shared_size) to read that value.
> >    c) When you receive the size from the remote you do
> >       atomic_set(&shared_size, size);
> >    d) The thread does:
> >       while (received_size < atomic_read(&shared_size))
> > 
> >       so the thread will quit either on EOF or it hitting the size.
> > 
> >    e) We pthread_join here to wait for the thread
> >    f) We then check a received size to make sure it matches what we
> > expect.
> > 
> > That removes the tight loop.
> 
> Sure, will do.
> 
> > 
> > > +    qemu_file_shutdown(f_remote);
> > > +
> > > +    qemu_fclose(f_remote);
> > > +    close(fd[1]);
> > > +
> > > +    return 0;
> > > +}
> > > +
> > > +static int proxy_post_save(void *opaque)
> > > +{
> > > +    MigrationState *ms = migrate_get_current();
> > > +    PCIProxyDev *pdev = opaque;
> > > +    uint64_t pos = 0;
> > > +
> > > +    while (pos < pdev->migsize) {
> > > +        qemu_put_byte(ms->to_dst_file, mig_data[pos]);
> > > +        pos++;
> > > +    }
> > > +
> > > +    qemu_fflush(ms->to_dst_file);
> > > +
> > > +    return 0;
> > 
> > I don't think you need that.
> > 
> > > +}
> > > +
> > > +const VMStateDescription vmstate_pci_proxy_device = {
> > > +    .name = "PCIProxyDevice",
> > > +    .version_id = 2,
> > > +    .minimum_version_id = 1,
> > > +    .pre_save = proxy_pre_save,
> > > +    .post_save = proxy_post_save,
> > > +    .fields = (VMStateField[]) {
> > > +        VMSTATE_PCI_DEVICE(parent_dev, PCIProxyDev),
> > > +        VMSTATE_UINT64(migsize, PCIProxyDev),
> > 
> > I think instead you should use a VMSTATE_VBUFFER here to save
> > the mig_data.
> > What we should do is the post_save should g_free the buffer.
> > (mig_data should be a field in proxy).
> 
> We noticed that VMSTATE_BUFFER requires that the buffer be part of a
> "struct" and that the buffer is an array. Since the buffer we're using
> is neither an array nor part of a "struct", we decided to go with
> writing the buffer directly to the migration stream in proxy_post_save()
> instead of using VMSTATE_BUFFER.
> 
> I think we should nevertheless g_free this buffer in post_save like you
> pointed out.

Note I'm suggesting using VMSTATE_VBUFFER, not VMSTATE_BUFFER;
VBUFFER is expecting a unsigned char *; it does expect that to be in
your structure, so I'd expect your proxy to have a mig_data and uint32_t
mig_len fields.

Dave

> Thank you!
> --
> Jag
> 
> > 
> > Dave
> > 
> > 
> > > +        VMSTATE_END_OF_LIST()
> > > +    }
> > > +};
> > > +
> > >   static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
> > >   {
> > >       PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> > > @@ -471,6 +605,7 @@ static void pci_proxy_dev_class_init(ObjectClass *klass, void *data)
> > >       k->config_write = pci_proxy_write_config;
> > >       dc->reset = proxy_device_reset;
> > > +    dc->vmsd = &vmstate_pci_proxy_device;
> > >   }
> > >   static const TypeInfo pci_proxy_dev_type_info = {
> > > diff --git a/include/hw/proxy/qemu-proxy.h b/include/hw/proxy/qemu-proxy.h
> > > index 5de8129..537c227 100644
> > > --- a/include/hw/proxy/qemu-proxy.h
> > > +++ b/include/hw/proxy/qemu-proxy.h
> > > @@ -75,6 +75,8 @@ struct PCIProxyDev {
> > >                           bool need_spawn, Error **errp);
> > >       ProxyMemoryRegion region[PCI_NUM_REGIONS];
> > > +
> > > +    uint64_t migsize;
> > >   };
> > >   typedef struct PCIProxyDevClass {
> > > diff --git a/include/io/mpqemu-link.h b/include/io/mpqemu-link.h
> > > index d2234ca..b42c003 100644
> > > --- a/include/io/mpqemu-link.h
> > > +++ b/include/io/mpqemu-link.h
> > > @@ -63,6 +63,7 @@ typedef enum {
> > >       PROXY_PING,
> > >       MMIO_RETURN,
> > >       DEVICE_RESET,
> > > +    START_MIG_OUT,
> > >       MAX,
> > >   } mpqemu_cmd_t;
> > > -- 
> > > 1.8.3.1
> > > 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2020-03-05 17:06 UTC|newest]

Thread overview: 117+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-24 20:54 [PATCH v5 00/50] Initial support for multi-process qemu Jagannathan Raman
2020-02-24 20:54 ` [PATCH v5 01/50] multi-process: memory: alloc RAM from file at offset Jagannathan Raman
2020-03-03 19:51   ` Dr. David Alan Gilbert
2020-03-04 18:24     ` Jag Raman
2020-02-24 20:54 ` [PATCH v5 02/50] multi-process: Refactor machine_init and exit notifiers Jagannathan Raman
2020-03-29 16:45   ` Marc-André Lureau
2020-02-24 20:54 ` [PATCH v5 03/50] multi-process: add a command line option for debug file Jagannathan Raman
2020-02-24 20:54 ` [PATCH v5 04/50] multi-process: Add stub functions to facilate build of multi-process Jagannathan Raman
2020-02-24 20:54 ` [PATCH v5 05/50] multi-process: Add config option for multi-process QEMU Jagannathan Raman
2020-02-24 20:54 ` [PATCH v5 06/50] multi-process: build system for remote device process Jagannathan Raman
2020-02-24 20:54 ` [PATCH v5 07/50] multi-process: define mpqemu-link object Jagannathan Raman
2020-03-10 16:09   ` Stefan Hajnoczi
2020-03-10 18:26     ` Elena Ufimtseva
2020-03-16 11:26       ` Stefan Hajnoczi
2020-02-24 20:54 ` [PATCH v5 08/50] multi-process: add functions to synchronize proxy and remote endpoints Jagannathan Raman
2020-03-03 19:56   ` Dr. David Alan Gilbert
2020-03-04 18:42     ` Jag Raman
2020-03-04 19:46       ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 09/50] multi-process: setup PCI host bridge for remote device Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 10/50] multi-process: setup a machine object for remote device process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 11/50] multi-process: setup memory manager for remote device Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 12/50] multi-process: remote process initialization Jagannathan Raman
2020-03-04 10:29   ` Dr. David Alan Gilbert
2020-03-04 18:45     ` Jag Raman
2020-03-04 19:00       ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 13/50] multi-process: introduce proxy object Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 14/50] mutli-process: build remote command line args Jagannathan Raman
2020-03-02 17:36   ` Philippe Mathieu-Daudé
2020-03-02 17:47     ` Daniel P. Berrangé
2020-03-02 22:39       ` Elena Ufimtseva
2020-03-04 11:00         ` Daniel P. Berrangé
2020-03-04 16:25           ` Elena Ufimtseva
2020-03-04 16:33             ` Daniel P. Berrangé
2020-03-04 22:37               ` Elena Ufimtseva
2020-03-05  8:21                 ` Daniel P. Berrangé
2020-03-06 16:25                   ` Stefan Hajnoczi
2020-03-04 10:09   ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 15/50] multi-process: PCI BAR read/write handling for proxy & remote endpoints Jagannathan Raman
2020-03-04 10:47   ` Dr. David Alan Gilbert
2020-03-04 19:05     ` Jag Raman
2020-02-24 20:55 ` [PATCH v5 16/50] multi-process: Synchronize remote memory Jagannathan Raman
2020-03-04 11:53   ` Dr. David Alan Gilbert
2020-03-04 19:35     ` Jag Raman
2020-02-24 20:55 ` [PATCH v5 17/50] multi-process: create IOHUB object to handle irq Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 18/50] multi-process: configure remote side devices Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 19/50] multi-process: Retrieve PCI info from remote process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 20/50] multi-process: add qdev_proxy_add to create proxy devices Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 21/50] multi-process: remote: add setup_devices msg processing Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 22/50] multi-process: remote: use fd for socket from parent process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 23/50] multi-process: remote: add create_done condition Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 24/50] multi-process: add processing of remote device command line Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 25/50] multi-process: Introduce build flags to separate remote process code Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 26/50] multi-process: refractor vl.c code Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 27/50] multi-process: add remote option Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 28/50] multi-process: add remote options parser Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 29/50] multi-process: add parse_cmdline in remote process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 30/50] multi-process: send heartbeat messages to remote Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 31/50] multi-process: handle heartbeat messages in remote process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 32/50] multi-process: Use separate MMIO communication channel Jagannathan Raman
2020-03-06 16:52   ` Stefan Hajnoczi
2020-03-10 18:04     ` Jag Raman
2020-02-24 20:55 ` [PATCH v5 33/50] multi-process: perform device reset in the remote process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 34/50] multi-process/mon: choose HMP commands based on target Jagannathan Raman
2020-03-05 10:39   ` Dr. David Alan Gilbert
2020-03-05 15:38     ` Jag Raman
2020-03-05 15:50       ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 35/50] multi-process/mon: stub functions to enable QMP module for remote process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 36/50] multi-process/mon: enable QMP module support in the " Jagannathan Raman
2020-03-05 10:43   ` Dr. David Alan Gilbert
2020-03-05 15:40     ` Jag Raman
2020-03-05 15:52       ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 37/50] multi-process/mon: Refactor monitor/chardev functions out of vl.c Jagannathan Raman
2020-03-05 10:51   ` Dr. David Alan Gilbert
2020-03-05 15:41     ` Jag Raman
2020-02-24 20:55 ` [PATCH v5 38/50] multi-process/mon: Initialize QMP module for remote processes Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 39/50] multi-process: prevent duplicate memory initialization in remote Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 40/50] multi-process/mig: build migration module in the remote process Jagannathan Raman
2020-03-04 15:58   ` Dr. David Alan Gilbert
2020-03-04 19:45     ` Jag Raman
2020-03-04 19:52       ` Dr. David Alan Gilbert
2020-03-04 20:23         ` Jag Raman
2020-03-05 10:10           ` Dr. David Alan Gilbert
2020-03-05 17:07             ` Elena Ufimtseva
2020-03-05 17:19               ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 41/50] multi-process/mig: Enable VMSD save in the Proxy object Jagannathan Raman
2020-03-05 12:31   ` Dr. David Alan Gilbert
2020-03-05 16:48     ` Jag Raman
2020-03-05 17:04       ` Dr. David Alan Gilbert [this message]
2020-02-24 20:55 ` [PATCH v5 42/50] multi-process/mig: Send VMSD of remote to " Jagannathan Raman
2020-03-05 14:39   ` Dr. David Alan Gilbert
2020-03-05 16:32     ` Elena Ufimtseva
2020-02-24 20:55 ` [PATCH v5 43/50] multi-process/mig: Load VMSD in the proxy object Jagannathan Raman
2020-03-05 15:28   ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 44/50] multi-process/mig: refactor runstate_check into common file Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 45/50] multi-process/mig: Synchronize runstate of remote process Jagannathan Raman
2020-02-24 20:55 ` [PATCH v5 46/50] multi-process/mig: Restore the VMSD in " Jagannathan Raman
2020-03-05 16:05   ` Dr. David Alan Gilbert
2020-02-24 20:55 ` [PATCH v5 47/50] multi-process: Enable support for multiple devices in remote Jagannathan Raman
2020-02-28 16:44   ` Stefan Hajnoczi
2020-03-02 19:28     ` Jag Raman
2020-02-24 20:55 ` [PATCH v5 48/50] multi-process: Validate incoming commands from Proxy Jagannathan Raman
2020-02-27 17:18   ` Stefan Hajnoczi
2020-02-28 17:53     ` Elena Ufimtseva
2020-02-24 20:55 ` [PATCH v5 49/50] multi-process: add the concept description to docs/devel/qemu-multiprocess Jagannathan Raman
2020-02-27 17:11   ` Stefan Hajnoczi
2020-02-28 18:44     ` Elena Ufimtseva
2020-02-24 20:55 ` [PATCH v5 50/50] multi-process: add configure and usage information Jagannathan Raman
2020-02-27 16:58   ` Stefan Hajnoczi
2020-02-28 18:43     ` Elena Ufimtseva
2020-03-06 16:42       ` Stefan Hajnoczi
2020-02-24 21:59 ` [PATCH v5 00/50] Initial support for multi-process qemu no-reply
2020-02-24 22:03 ` no-reply
2020-02-24 22:23 ` no-reply
2020-03-01 11:57 ` Alex Bennée
2020-03-02 15:28   ` Jag Raman
2020-03-02 16:29     ` Alex Bennée
2020-03-02 16:53       ` Jag Raman

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=20200305170422.GN3130@work-vm \
    --to=dgilbert@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@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=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=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 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.