[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to guest memory access functions
Date: Mon, 21 May 2012 11:31:33 +0300

On Mon, May 21, 2012 at 10:11:06AM +0200, Paolo Bonzini wrote:
> Il 21/05/2012 03:56, Benjamin Herrenschmidt ha scritto:
> > I don't see an obvious need to provide a "relaxed" variant of the
> > later at this stage, a quick grep doesn't seem to show that most cases
> > where it's used are either not performance sensitive or the barrier
> > makes sense, but feel free to prove me wrong :-)
> The only problem here is that you have useless memory barriers when
> calling cpu_physical_memory_map in a loop (see virtqueue_map_sg).
> Paolo

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

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
I really don't see why don't we audit devices
and add proper barriers.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]