[U-Boot] [PATCH 03/27] virtio: Add codes for virtual queue/ring management

[Bin Meng]

Hi Tuomas,

On Fri, Sep 28, 2018 at 6:11 AM Tuomas Tynkkynen
<tuomas.tynkkynen at iki.fi> wrote:
>
> Hi Bin,
>
> On 09/23/2018 04:42 PM, Bin Meng wrote:
> > From: Tuomas Tynkkynen <tuomas.tynkkynen at iki.fi>
> >
> > This adds support for managing virtual queue/ring, the channel
> > for high performance I/O between host and guest.
> >
> > Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen at iki.fi>
> > Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
> > ---
> ...
>
> > +
> > +/*
> > + * Barriers in virtio are tricky. Since we are not in a hyperviosr/guest
> > + * scenario, having these as nops is enough to work as expected.
> > + */
> > +
> > +static inline void virtio_mb(void)
> > +{
> > +}
> > +
> > +static inline void virtio_rmb(void)
> > +{
> > +}
> > +
> > +static inline void virtio_wmb(void)
> > +{
> > +}
> > +
> > +static inline void virtio_store_mb(__virtio16 *p, __virtio16 v)
> > +{
> > +     WRITE_ONCE(*p, v);
> > +}
> > +
> > +#endif /* _LINUX_VIRTIO_RING_H */
> >
> I am not convinced it's safe to leave these barriers empty. For instance
> if KVM acceleration is used, I believe U-Boot could be running on one
> core concurrently with QEMU's IO thread running on a different core.
> Thus we need memory barriers on both sides so that updates to the
> vring are observed in the correct order.

I think KVM acceleration only applies if hypervisor/guest are of the
same architecture. So far we are not using QEMU this way, even in QEMU
x86. Hence I believe barriers are not needed.

Regards,
Bin

Regards,
Bin