Re: [Qemu-devel] [PATCH] Add a memory barrier to guest memory access functions

[Anthony Liguori]

On 05/21/2012 03:31 AM, Michael S. Tsirkin wrote:
> More than that. smp_mb is pretty expensive. You
> often can do just smp_wmb and smp_rmb and that is
> very cheap.
> Many operations run in the vcpu context
> or start when guest exits to host and work
> is bounced from there and thus no barrier is needed
> here.
>
> Example? start_xmit in e1000. Executed in vcpu context
> so no barrier is needed.
>
> virtio of course is another example since it does its own
> barriers. But even without that, virtio_blk_handle_output
> runs in vcpu context.
>
> But more importantly, this hack just sweeps the
> dirt under the carpet. Understanding the interaction
> with guest drivers is important anyway. So

But this isn't what this series is about.

This series is only attempting to make sure that writes are ordered with respect 
to other writes in main memory.

It's based on the assumption that write ordering is well defined (and typically 
strict) on most busses including PCI.  I have not confirmed this myself but I 
trust that Ben has.

So the only problem trying to be solved here is to make sure that if a write A 
is issued by the device model while it's on PCPU 0, if PCPU 1 does a write B to 
another location, and then the device model runs on PCPU 2 and does a read of 
both A and B, it will only see the new value of B if the it sees the new value of A.

Whether the driver on VCPU 0 (which may be on any PCPU) also sees the write 
ordering is irrelevant.

If you want to avoid taking a barrier on every write, we can make use of map() 
and issue explicit barriers (as virtio does).

Regards,

Anthony Liguori

> I really don't see why don't we audit devices
> and add proper barriers.