Re: [Qemu-devel] [RFC/PATCH] Add a memory barrier to guest memory access functions

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2012-05-17 at 17:09 -0500, Anthony Liguori wrote:

> ld/st should not ever be used by device emulation because they use a concept of 
> "target endianness" that doesn't exist for devices.

Hrm, there's a bit of both, some of them even have explicit endianness
arguments and some of them are definitely used by bits of hw/*

virtio core uses them directly as well but then virtio also does
explicit barriers (though I need to double check whether it does enough
of them in all the right places).

> So no, I don't think you need to put barriers there as they should only be used 
> by VCPU emulation code.

I'm ok to leave them alone for now, I'll give a quick look at the
various callers.

> > Note that with the above, cpu_physical_memory_map and unmap will
> > imply a barrier when using bounce buffers, it would make sense to also
> > provide the same barrier when not.
> >
> > That does actually make sense for the same reason explained above,
> > ie, when those are used for a DMA transfer via async IO, that guarantees
> > ordering of the "block" vs. surrounding accesses even if accesses within
> > the actual map/unmap region are not ordered vs. each other.
> >
> > Any objection ?
> 
> I think so.  I'd like to see a better comment about barrier usage at the top of 
> the file or something like that too.

Ok.

Cheers,
Ben.

> Regards,
> 
> Anthony Liguori
> 
> >
> > Cheers,
> > Ben.
> >
> >
> >