Re: [Qemu-devel] [Qemu-block] [PATCH] Added iopmem device emulation

[Stefan Hajnoczi]

On Tue, Nov 08, 2016 at 09:46:47AM -0700, Logan Gunthorpe wrote:
> On 08/11/16 08:58 AM, Stefan Hajnoczi wrote:
> > My concern with the current implementation is that a PCI MMIO access
> > invokes a synchronous blk_*() call.  That can pause vcpu execution while
> > I/O is happening and therefore leads to unresponsive guests.  QEMU's
> > monitor interface is also blocked during blk_*() making it impossible to
> > troubleshoot QEMU if it gets stuck due to a slow/hung I/O operation.
> > 
> > Device models need to use blk_aio_*() so that control is returned while
> > I/O is running.  There are a few legacy devices left that use
> > synchronous I/O but new devices should not use this approach.
> 
> That's fair. I wasn't aware of this and I must have copied a legacy
> device. We can certainly make the change in our patch.
> 
> > Regarding the hardware design, I think the PCI BAR approach to nvdimm is
> > inefficient for virtualization because each memory load/store requires a
> > guest<->host transition (vmexit + vmenter).  A DMA approach (i.e.
> > message passing or descriptor rings) is more efficient because it
> > requires fewer vmexits.
> > 
> > On real hardware the performance characteristics are different so it
> > depends what your target market is.
> 
> The performance of the virtual device is completely unimportant. This
> isn't something I'd expect anyone to use except to test drivers. On real
> hardware, with real applications, DMA would almost certainly be used --
> but it would be the DMA engine in another device. eg. an IB NIC would
> DMA from the PCI BAR of the iopmem device. This completely bypasses the
> CPU so there would be no load/stores to be concerned about.

Okay, sounds good.

Is there a reason to use the block layer in QEMU?  Perhaps it's better
to do the same as the nvdimm device in QEMU and use a memory backend
instead.  The memory backend can be MAP_PRIVATE or MAP_SHARED.  It can
be anonymous memory or it can be backed by a real file.  This gives you
options can avoids using the QEMU block layer in a way it wasn't
designed.

Doing this would forgo QEMU block layer features like image file formats
(qcow2), block jobs (storage migration), etc.  But those probably aren't
necessary for this device.

Stefan

signature.asc
Description: PGP signature