On 4/7/2015 10:23 PM, Luke Gorrie wrote: > Hi Michael, > > I'm writing to follow up the previous discussion about memory barriers in > virtio-net device implementations, and Cc'ing the DPDK list because I > believe this is relevant to them too. > > First, thanks again for getting in touch and reviewing our code. > > I have now found a missed case where we *do* require a hardware memory > barrier on x86 in our vhost/virtio-net device. That is when checking the > interrupt suppression flag after updating used->idx. This is needed because > x86 can reorder the write to used->idx after the read from avail->flags, > and that causes the guest to see a stale value of used->idx after it > toggles interrupt suppression. luke: 1. host read the flag. 2 guest toggles the flag 3.guest checks the used. 4. host update used. Is this your case? > > If I may spell out my mental model, for the sake of being corrected and/or > as an example of how third party developers are reading and interpreting > the Virtio-net spec: > > Relating this to Virtio 1.0, the most relevant section is 3.2.1 (Supplying > Buffers to the Device) which calls for two "suitable memory barriers". The > spec talks about these from the driver perspective, but they are both > relevant to the device side too. > > The first barrier (write to descriptor table before write to used->idx) is > implicit on x86 because writes by the same core are not reordered. This > means that no explicit hardware barrier is needed. (A compiler barrier may > be needed, however.) > > The second memory barrier (write to used->idx before reading avail->flags) > is not implicit on x86 because stores are reordered after loads. So an > explicit hardware memory barrier is needed. > > I hope that is a correct assessment of the situation. (Forgive my > x86centricity, I am sure that seems very foreign to kernel hackers.) > > If this assessment is correct then the DPDK developers might also want to > review librte_vhost/vhost_rxtx.c and consider adding a hardware memory > barrier between writing used->idx and reading avail->flags. > > Cheers, > -Luke > > P.S. I notice that the Linux virtio-net driver does not seem to tolerate > spurious interrupts, even though the Virtio 1.0 spec requires this > ("must"). On 3.13.11-ckt15 I see them trigger an "irq nobody cared" kernel > log message and then the irq is disabled. If that sounds suspicious I can > supply more information. > > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization