On 01/21/2010 07:10 PM, Michael S. Tsirkin wrote:
Documentation/memory-barriers.txt says:
Mandatory barriers should not be used to control SMP effects, since
mandatory barriers unnecessarily impose overhead on UP systems.
This rule applies to virtio, so let's do it correctly.
This is
On Wed, Jan 27, 2010 at 11:28:32AM +0200, Avi Kivity wrote:
On 01/21/2010 07:10 PM, Michael S. Tsirkin wrote:
Documentation/memory-barriers.txt says:
Mandatory barriers should not be used to control SMP effects, since
mandatory barriers unnecessarily impose overhead on UP systems.
This rule
On 01/27/2010 11:36 AM, Michael S. Tsirkin wrote:
smp_mb() is used for processor-vs-processor ordering, which can't happen
on UP systems, but for process-vs-device, we must use mb().
(this shows up if running a UP guest on an SMP host).
Currently, yes. But virtio is not a real
On Wed, Jan 27, 2010 at 11:46:32AM +0200, Avi Kivity wrote:
On 01/27/2010 11:36 AM, Michael S. Tsirkin wrote:
smp_mb() is used for processor-vs-processor ordering, which can't happen
on UP systems, but for process-vs-device, we must use mb().
(this shows up if running a UP guest on an SMP
virtio is communicating with a virtual device that actually runs on
another host processor. Thus SMP barriers can be used to control
memory access ordering.
Where possible, we should use SMP barriers which are more lightweight than
mandatory barriers, because mandatory barriers also control MMIO
On Thu, 28 Jan 2010 09:12:23 am Michael S. Tsirkin wrote:
virtio is communicating with a virtual device that actually runs on
another host processor. Thus SMP barriers can be used to control
memory access ordering.
Where possible, we should use SMP barriers which are more lightweight than
