[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] Added iopmem device emulation
Date: Wed, 9 Nov 2016 09:58:28 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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

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.


Attachment: signature.asc
Description: PGP signature

reply via email to

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