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.