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
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 or
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 gue
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 bo
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 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
he
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 exa
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
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 mu
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:
> > >
> > > > On
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 "rem
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)
> > th
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, 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'
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 d
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 no
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
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 functio
18 matches
Mail list logo
