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
