[Top][All Lists]

[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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]