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
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
On Mon, 2012-05-21 at 11:31 +0300, Michael S. Tsirkin wrote:
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
On Mon, 2012-05-21 at 18:58 +1000, Benjamin Herrenschmidt wrote:
Except that you mostly don't know at that level what you can or cannot
do, it depends on the caller. We should have the standard accessors do
it the safe way and have performance sensitive stuff do map/unmap, at
least that's the
On Mon, 2012-05-21 at 19:07 +1000, Benjamin Herrenschmidt wrote:
One thing that might alleviate some of your concerns would possibly be
to remember in a global (to be replaced with a thread var eventually)
the last transfer direction and use a simple test to chose the barrier,
ie, store +
On Mon, May 21, 2012 at 07:16:27PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 19:07 +1000, Benjamin Herrenschmidt wrote:
One thing that might alleviate some of your concerns would possibly be
to remember in a global (to be replaced with a thread var eventually)
the last
On Mon, 2012-05-21 at 12:34 +0300, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 07:16:27PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 19:07 +1000, Benjamin Herrenschmidt wrote:
One thing that might alleviate some of your concerns would possibly be
to remember in a
On Mon, May 21, 2012 at 07:53:23PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 12:34 +0300, Michael S. Tsirkin wrote:
On Mon, May 21, 2012 at 07:16:27PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 19:07 +1000, Benjamin Herrenschmidt wrote:
One thing that
On Mon, 2012-05-21 at 13:31 +0300, Michael S. Tsirkin wrote:
IE. Just making the default accessors ordered means that all devices
written with the assumption that the guest will see accesses in the
order they are written in the emulated device will be correct, which
means pretty much all
On Mon, May 21, 2012 at 09:45:58PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 13:31 +0300, Michael S. Tsirkin wrote:
IE. Just making the default accessors ordered means that all devices
written with the assumption that the guest will see accesses in the
order they are
Il 21/05/2012 14:18, Michael S. Tsirkin ha scritto:
Almost all our
devices were written without any thought given to ordering, so they
basically can and should be considered as all broken.
Problem is, a lot of code is likely broken even after you sprinkle
barriers around. For example qemu
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
On Mon, 2012-05-21 at 17:18 -0500, Anthony Liguori wrote:
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.
Actually, it applies to both reads and writes. They can't pass each
other
On 05/21/2012 05:26 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 17:18 -0500, Anthony Liguori wrote:
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.
Actually, it applies to
On Mon, May 21, 2012 at 05:18:21PM -0500, Anthony Liguori wrote:
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
On Mon, May 21, 2012 at 05:31:06PM -0500, Anthony Liguori wrote:
On 05/21/2012 05:26 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 17:18 -0500, Anthony Liguori wrote:
But this isn't what this series is about.
This series is only attempting to make sure that writes are ordered
with
On Tue, 2012-05-22 at 01:44 +0300, Michael S. Tsirkin wrote:
OK. Just not another level of indirect function callbacks please. Make
it a library so each bus can do the right thing. There are not so many
buses.
I think we are a long way from having to deal with subtly different
ordering
The emulated devices can run simultaneously with the guest, so
we need to be careful with ordering of load and stores done by
them to the guest system memory, which need to be observed in
the right order by the guest operating system.
This adds barriers to some standard guest memory access
18 matches
Mail list logo
