Re: Proposal for MMIO/PIO dispatch file descriptors (ioregionfd)

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 25, 2020 at 09:24:34AM +0000, Stefan Hajnoczi wrote:
> On Mon, Feb 24, 2020 at 12:10:25PM -0500, Michael S. Tsirkin wrote:
> > On Sat, Feb 22, 2020 at 08:19:16PM +0000, Stefan Hajnoczi wrote:
> > > The KVM_IOREGIONFD_POSTED_WRITES flag
> > > skips waiting for an acknowledgement on write accesses.  This is
> > > suitable for accesses that do not require synchronous emulation, such as
> > > doorbell register writes.
> > 
> > I would avoid hacks like this until we understand this better.
> > Specificlly one needs to be very careful since memory ordering semantics
> > can differ between a write into an uncacheable range and host writes into
> > a data structure. Reads from one region are also assumed to be ordered with
> > writes to another region, and drivers are known to make assumptions
> > like this.
> > 
> > Memory ordering being what it is, this isn't a field I'd be comfortable
> > device writes know what they are doing.
> 
> Unlike PCI Posted Writes the idea is not to let the write operations sit
> in a cache.  They will be sent immediately just like ioeventfd is
> signalled immediately before re-entering the guest.

But ioeventfd sits in the cache: the internal counter. The fact it's
signalled does not force a barrier on the signalling thread.  It looks
like the same happens here: value is saved with the file descriptor,
other accesses of the same device can bypass the write.

> The purpose of this feature is to let the device emulation program
> handle these writes asynchronously (without holding up the vCPU for a
> response from the device emulation program) but the order of
> reads/writes remains unchanged.
> 
> Stefan

I don't see how this can be implemented without guest changes though.
For example, how do you make sure two writes to such regions are ordered
just like they are on PCI?

-- 
MST