[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH v20 01/20] multi-process: add the concept description to docs
From: |
Thanos Makatos |
Subject: |
RE: [PATCH v20 01/20] multi-process: add the concept description to docs/devel/qemu-multiprocess |
Date: |
Thu, 28 Jan 2021 09:53:46 +0000 |
> > I understand that this framework is targetting KVM and mostly PCI
> > devices but I was wondering if it could be of any use for full system
> > emulation. Would it possible to use this framework to interconnect
> > QEMU processes emulating different machines but sharing a common bus
> ?
Not sure I understand what you mean by "sharing a common bus", rre you talking
about a shared bus where a message sent by one QEMU process is visible by all
other QEMU processes?
>
> We are eventually moving towards a vfio-user framework which implements
> VFIO over socket. What you are envisioning could be something in the
> evolution of QEMU devices in the future, although VFIO does not support all
> types of devices presently.
>
> I am following the efforts to modularize QEMU devices into runtime libraries,
> which probably would be one of the significant steps to emulating devices in
> distributed fashion.
>
> >
> > Using the proxy object, could a "slave" QEMU machine (host) connect to
> > a remote device implemented in another QEMU (bmc) machine ? or are we
> > considering that remote processes are dedicated to device modeling and
> > no more.
>
> Presently, we are addressing the case where the remote device is in the
> same machine as QEMU. Moving the remote device to a different machine
> has a network bottleneck - the performance of such a model would depend
> on the performance of various protocols like RDMA (for remote DMA), etc...
The vfio-user protocol does support the remote device use case. As Jag pointed
out, performance will be poor (there might (?) be ways to improve it), but if
communication is only occasional then it might work fine. The vfio-user
protocol is intended for remote device implementations, however this doesn't
preclude being used for a different purpose, provided that its primitives are
sufficient. What would your requirements be?
>
> Thank you!
> —
> Jag
>
> >
> > What I have in mind for the moment is LPC, FW address space and some
> > ISA devices, but the list could extend.
What's the benefit or running a device remotely in your use case?
- [PATCH v20 00/20] Initial support for multi-process Qemu, Jagannathan Raman, 2021/01/19
- [PATCH v20 04/20] multi-process: Add config option for multi-process QEMU, Jagannathan Raman, 2021/01/19
- [PATCH v20 06/20] multi-process: setup a machine object for remote device process, Jagannathan Raman, 2021/01/19
- [PATCH v20 05/20] multi-process: setup PCI host bridge for remote device, Jagannathan Raman, 2021/01/19
- [PATCH v20 07/20] io: add qio_channel_writev_full_all helper, Jagannathan Raman, 2021/01/19
- [PATCH v20 08/20] io: add qio_channel_readv_full_all_eof & qio_channel_readv_full_all helpers, Jagannathan Raman, 2021/01/19
- [PATCH v20 09/20] multi-process: define MPQemuMsg format and transmission functions, Jagannathan Raman, 2021/01/19
- [PATCH v20 12/20] multi-process: setup memory manager for remote device, Jagannathan Raman, 2021/01/19
- [PATCH v20 15/20] multi-process: Forward PCI config space acceses to the remote process, Jagannathan Raman, 2021/01/19
- [PATCH v20 17/20] multi-process: Synchronize remote memory, Jagannathan Raman, 2021/01/19