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

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

On Mon, Nov 07, 2016 at 10:09:29AM -0700, Logan Gunthorpe wrote:
> On 07/11/16 03:28 AM, Stefan Hajnoczi wrote:
> > It may be too early to merge this code into qemu.git if there is no
> > hardware spec and this is a prototype device that is subject to change.
> 
> Fair enough, though the interface is so simple I don't know what could
> possibly change.

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.

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.

> > I'm wondering if there is a way to test or use this device if you are
> > not releasing specs and code that drives the device.
> > 
> > Have you submitted patches to enable this device in Linux, DPDK, or any
> > other project?
> 
> Yes, you can find patches to the Linux Kernel that were submitted to a
> couple mailing lists at the same time as the QEMU patch:
> 
> http://www.mail-archive.com/linux-nvdimm@lists.01.org/msg01426.html
> 
> There's been a discussion as to how best to expose these devices to user
> space and we may take a different approach in v2. But there has been no
> indication that the PCI interface would need to change at all.

Thanks, I'll check out the discussion!

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]