On Mon, 14 Apr 2025 08:44:07 -0700 Fan Ni <nifan....@gmail.com> wrote:
> On Tue, Apr 08, 2025 at 11:04:20AM -0400, Gregory Price wrote: > > On Mon, Apr 07, 2025 at 09:20:27PM -0700, nifan....@gmail.com wrote: > > > From: Fan Ni <fan...@samsung.com> > > > > > > The RFC provides a way for FM emulation in Qemu. The goal is to provide > > > a context where we can have more FM emulation discussions and share > > > solutions > > > for a reasonable FM implementation in Qemu. > > > > > ... snip ... > > > > Took a browse of the series, and I like this method. It seems simple > > and straight-forward, avoids any complex networking between the vms and > > gives us what we want. > > > > I'll wait for Jonathan's commentary, but solid prototype (bn_n)b > > > > ~Gregory > > Hi Jonathan, > > Any feedback for this RFC? Immediate question is whether anything similar is done in other use cases in QEMU? There are vaguely similar things that work via a socket but I'm not sure the mix of a shared buffer and a qmp based doorbell is done elsewhere. There is use of shared memory for inter VM comms but that uses a socket for it's doorbell / interrupt path, not qmp. https://www.qemu.org/docs/master/specs/ivshmem-spec.html So without looking in that much detail yet, I'm not yet convinced this is preferable to a socket over which we can send the mctp packets. In general we need to also solve how to upstream the mctp support in qemu or this is adding yet more stuff to my cxl staging tree. +CC Markus for QMP part. https://lore.kernel.org/all/20250408043051.430340-1-nifan....@gmail.com/ is start of thread. https://lore.kernel.org/all/20250408043051.430340-3-nifan....@gmail.com/ the qmp patch adding what is more or less a doorbell pinged by a device on a different QEMU instance. Jonathan > > Fan
