On Thu, 24 Dec 2009 03:06:00 am Michael S. Tsirkin wrote:
> On Wed, Dec 23, 2009 at 05:04:19PM +1030, Rusty Russell wrote:
> > It's possible, but I don't know of any missing cases. Certainly *lguest* i
> > is missing barriers, since it's UP, but the core virtio should have them.
>
> Something tha
On Wed, Dec 23, 2009 at 05:04:19PM +1030, Rusty Russell wrote:
> On Wed, 23 Dec 2009 01:21:43 am Anthony Liguori wrote:
> > On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
> > > On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
> > >
> > >> The following fixes a class of lon
On Wed, Dec 23, 2009 at 03:13:05PM +, Paul Brook wrote:
> > > > > Given we need both, why not actually defined an API that gives you
> > > > > this?
> > > >
> > > > Because, I do not want to define APIs, I want to reuse an existing one.
> > >
> > > Except that, say you said later in your email,
> > > > Given we need both, why not actually defined an API that gives you
> > > > this?
> > >
> > > Because, I do not want to define APIs, I want to reuse an existing one.
> >
> > Except that, say you said later in your email, no API exists for doing
> > atomic accesses, so you need different code
On Wed, Dec 23, 2009 at 01:32:53PM +, Paul Brook wrote:
> On Wednesday 23 December 2009, Michael S. Tsirkin wrote:
> > On Wed, Dec 23, 2009 at 12:25:46PM +, Paul Brook wrote:
> > > > > > So possibly this means that we
> > > > > > could optimize the barrier away, but I don't think this amoun
On Wednesday 23 December 2009, Michael S. Tsirkin wrote:
> On Wed, Dec 23, 2009 at 12:25:46PM +, Paul Brook wrote:
> > > > > So possibly this means that we
> > > > > could optimize the barrier away, but I don't think this amounts to
> > > > > a serious issue, I guess portability/readability is
On Wed, Dec 23, 2009 at 12:25:46PM +, Paul Brook wrote:
> > > > So possibly this means that we
> > > > could optimize the barrier away, but I don't think this amounts to a
> > > > serious issue, I guess portability/readability is more important.
> > >
> > > The more important issue is that regu
> > > So possibly this means that we
> > > could optimize the barrier away, but I don't think this amounts to a
> > > serious issue, I guess portability/readability is more important.
> >
> > The more important issue is that regular devices which to not require
> > coherency or ordering can omit th
On Wed, Dec 23, 2009 at 01:58:04PM +0200, Michael S. Tsirkin wrote:
> > Where does it say that stw_phys is atomic?
> >
> > By my reading stw_phys is implemented using memcpy. This means that it is
> > almost certainly not atomic. My guess is that this works entirely by
> > chance,
> > because
On Wed, Dec 23, 2009 at 11:36:34AM +, Paul Brook wrote:
> > > I mean have a single function that does both the atomic load/store and
> > > the memory barrier. Instead of:
> > >
> > > stw_phys(addr, val)
> > > barrier();
> > >
> > > We do:
> > >
> > > stw_phys_barrier(addr, val).
> >
> >
> > I mean have a single function that does both the atomic load/store and
> > the memory barrier. Instead of:
> >
> > stw_phys(addr, val)
> > barrier();
> >
> > We do:
> >
> > stw_phys_barrier(addr, val).
>
> Well, I think it's a good idea to use Linux APIs instead of
> inventing our own. A
On Tue, Dec 22, 2009 at 10:58:16PM +, Paul Brook wrote:
> > > Given this is supposed to be portable code, I wonder if we should have
> > > atomic ordered memory accessors instead.
> > >
> > > Paul
> >
> > Could you clarify please?
> >
> > The infiniband bits I used as base are very portable,
On Wed, 23 Dec 2009 01:21:43 am Anthony Liguori wrote:
> On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
> >
> >> The following fixes a class of long-standing bugs in qemu:
> >> when kvm is enabled, guest might access dev
> > Given this is supposed to be portable code, I wonder if we should have
> > atomic ordered memory accessors instead.
> >
> > Paul
>
> Could you clarify please?
>
> The infiniband bits I used as base are very portable,
> I know they build on a ton of platforms. I just stripped
> a couple of inf
On 12/22/2009 06:25 PM, Paul Brook wrote:
On Tuesday 22 December 2009, Anthony Liguori wrote:
On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
The following fixes a class of long-standing bugs in qemu:
when
On Tue, Dec 22, 2009 at 04:25:32PM +, Paul Brook wrote:
> On Tuesday 22 December 2009, Anthony Liguori wrote:
> > On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
> > > On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
> > >> The following fixes a class of long-standing bugs
On Tuesday 22 December 2009, Anthony Liguori wrote:
> On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
> >> The following fixes a class of long-standing bugs in qemu:
> >> when kvm is enabled, guest might access device structu
On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
The following fixes a class of long-standing bugs in qemu:
when kvm is enabled, guest might access device structures
in memory while they are updated by qemu on another CPU.
On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
> The following fixes a class of long-standing bugs in qemu:
> when kvm is enabled, guest might access device structures
> in memory while they are updated by qemu on another CPU.
> In this scenario, memory barriers are necessary t
19 matches
Mail list logo
