Hi Tuomas, On Fri, Sep 28, 2018 at 6:11 AM Tuomas Tynkkynen <tuomas.tynkky...@iki.fi> wrote: > > Hi Bin, > > On 09/23/2018 04:42 PM, Bin Meng wrote: > > From: Tuomas Tynkkynen <tuomas.tynkky...@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.tynkky...@iki.fi> > > Signed-off-by: Bin Meng <bmeng...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot