Re: memory barriers in virtq.lua?

[Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>]

Hello Michael,


On Tue, Jan 27, 2015 at 6:01 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> Hi Nikolay,
> I poked at src/lib/virtio/virtq.lua a bit -
> I was surprised to find no explicit CPU memory
> barriers in the virtq implementation.
> These are typically required when using virtio
> on smp machines - the spec actually mention where
> barriers are necessary.
> Are the barriers implicit somehow for lua?
> I'd be curious to learn.
>


thanks for looking at our code and providing your feedback.

The virtq.lua implements the virtq operations from a device point of
view. We compile this with LuaJIT which is guaranteed to not reorder
operations [1]. We also target the x86 architecture, which is
guaranteed to not reorder stores [2]:
"Stores Are Seen in a Consistent Order by Other Processors".
We rely on both these facts and don't use barrier in the virtq code.
However I do agree that we'll have to put barriers once we switch to
other architectures and/or LuaJIT implements ordering optmisations.

Finally, I checked the virtio 1.0 spec again and didn't see any
explicit mentioning of memory barriers regarding the device side of
the spec. There are several places where memory barriers are mentioned
and these all are about the driver. Maybe they are omitted because
they are implicit somehow? Please clarify.

regards,
Nikolay Nikolaev

[1] https://www.freelists.org/post/luajit/Compiler-loadstore-barrier-volatile-pointer-barriers-in-general,1
[2] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
 - 8.2.3.7

>
> Thanks,
>
> --
> MST