On 09/06/2011 11:28 AM, Avi Kivity wrote:
Actually Michael is right. The implementation is correct on x86,
though wrong anywhere else (perhaps s390?). On those architectures
you do not need rmb() and wmb().
Are we sure? Nothing prevents the guest from using weakly-ordered
writes, is there?
On Tue, Sep 06, 2011 at 12:28:40PM +0300, Avi Kivity wrote:
> On 09/06/2011 09:55 AM, Paolo Bonzini wrote:
> >On 09/06/2011 05:12 AM, David Gibson wrote:
> >>I'm not "fixing ppc". I'm fixing a fundamental flaw in the protocol
> >>implementation._So far_ I've only observed the effects on ppc, but
On 09/06/2011 09:55 AM, Paolo Bonzini wrote:
On 09/06/2011 05:12 AM, David Gibson wrote:
I'm not "fixing ppc". I'm fixing a fundamental flaw in the protocol
implementation._So far_ I've only observed the effects on ppc, but
that doesn't mean they don't exist.
Actually Michael is right. The
On Tue, Sep 06, 2011 at 08:55:42AM +0200, Paolo Bonzini wrote:
> On 09/06/2011 05:12 AM, David Gibson wrote:
> >I'm not "fixing ppc". I'm fixing a fundamental flaw in the protocol
> >implementation._So far_ I've only observed the effects on ppc, but
> >that doesn't mean they don't exist.
>
> Act
On 09/06/2011 05:12 AM, David Gibson wrote:
I'm not "fixing ppc". I'm fixing a fundamental flaw in the protocol
implementation._So far_ I've only observed the effects on ppc, but
that doesn't mean they don't exist.
Actually Michael is right. The implementation is correct on x86, though
wron
On Mon, Sep 05, 2011 at 12:19:46PM +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 05, 2011 at 02:43:16PM +1000, David Gibson wrote:
> > On Sun, Sep 04, 2011 at 12:16:43PM +0300, Michael S. Tsirkin wrote:
> > > On Sun, Sep 04, 2011 at 12:46:35AM +1000, David Gibson wrote:
> > > > On Fri, Sep 02, 201
> > No, rmb and wmb need to generate code.
>
> If they do we'll have to surround each their use with
> ifndef x86 as you suggest later. Which is just messy.
[1 hour later]
I see what you mean now. You assume there are no accesses to
write-combining memory (of course) or non-temporal load/stores
On Mon, Sep 05, 2011 at 02:43:16PM +1000, David Gibson wrote:
> On Sun, Sep 04, 2011 at 12:16:43PM +0300, Michael S. Tsirkin wrote:
> > On Sun, Sep 04, 2011 at 12:46:35AM +1000, David Gibson wrote:
> > > On Fri, Sep 02, 2011 at 06:45:50PM +0300, Michael S. Tsirkin wrote:
> > > > On Thu, Sep 01, 201
On Mon, Sep 05, 2011 at 09:41:19AM +0200, Paolo Bonzini wrote:
> On 09/04/2011 11:16 AM, Michael S. Tsirkin wrote:
> >>> I mean argue for a richer set of barriers, with per-arch minimal
> >>> implementations instead of the large but portable hammer of
> >>> sync_synchronize, if you will.
> >
> >
On 09/04/2011 11:16 AM, Michael S. Tsirkin wrote:
> I mean argue for a richer set of barriers, with per-arch minimal
> implementations instead of the large but portable hammer of
> sync_synchronize, if you will.
That's what I'm saying really. On x86 the richer set of barriers
need not insert
On Sun, Sep 04, 2011 at 12:16:43PM +0300, Michael S. Tsirkin wrote:
> On Sun, Sep 04, 2011 at 12:46:35AM +1000, David Gibson wrote:
> > On Fri, Sep 02, 2011 at 06:45:50PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Sep 01, 2011 at 04:31:09PM -0400, Paolo Bonzini wrote:
> > > > > > > Why not limi
On Sun, Sep 04, 2011 at 12:46:35AM +1000, David Gibson wrote:
> On Fri, Sep 02, 2011 at 06:45:50PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Sep 01, 2011 at 04:31:09PM -0400, Paolo Bonzini wrote:
> > > > > > Why not limit the change to ppc then?
> > > > >
> > > > > Because the bug is masked by t
On Sat, Sep 03, 2011 at 06:19:23PM +0200, Paolo Bonzini wrote:
> On 09/02/2011 05:45 PM, Michael S. Tsirkin wrote:
> >Well, can you describe an issue in virtio that lfence/sfence help solve
> >in terms of a memory model please?
> >Pls note that guest uses smp_ variants for barriers.
>
> /* Mak
On Fri, Sep 02, 2011 at 06:45:50PM +0300, Michael S. Tsirkin wrote:
> On Thu, Sep 01, 2011 at 04:31:09PM -0400, Paolo Bonzini wrote:
> > > > > Why not limit the change to ppc then?
> > > >
> > > > Because the bug is masked by the x86 memory model, but it is still
> > > > there even there conceptual
On 09/02/2011 05:45 PM, Michael S. Tsirkin wrote:
Well, can you describe an issue in virtio that lfence/sfence help solve
in terms of a memory model please?
Pls note that guest uses smp_ variants for barriers.
/* Make sure buffer is written before we update index. */
wmb();
Without it,
On Fri, Sep 2, 2011 at 6:49 AM, Paolo Bonzini wrote:
> On 09/02/2011 02:08 AM, David Gibson wrote:
>>>
>>> >
> >Signed-off-by: Alexey Kardashevskiy
> >Signed-off-by: David Gibson
>>>
>>> >
>>> > It will most definitely break OpenBSD, but anyway:
>>
>> Uh, why?
>
> They use an anc
On Fri, Sep 02, 2011 at 08:11:29AM +0200, Paolo Bonzini wrote:
> On 09/02/2011 02:11 AM, David Gibson wrote:
> >Why not limit the change to ppc then?
> >>>
> >>> Because the bug is masked by the x86 memory model, but it is still
> >>> there even there conceptually. It is not really true th
On Thu, Sep 01, 2011 at 04:31:09PM -0400, Paolo Bonzini wrote:
> > > > Why not limit the change to ppc then?
> > >
> > > Because the bug is masked by the x86 memory model, but it is still
> > > there even there conceptually. It is not really true that x86 does
> > > not need memory barriers, though
On 09/02/2011 02:08 AM, David Gibson wrote:
>
> >Signed-off-by: Alexey Kardashevskiy
> >Signed-off-by: David Gibson
>
> It will most definitely break OpenBSD, but anyway:
Uh, why?
They use an ancient compiler because they do not want to use GPLv3. I
thought it was 4.1.something but actu
On 09/02/2011 02:11 AM, David Gibson wrote:
> >Why not limit the change to ppc then?
>
> Because the bug is masked by the x86 memory model, but it is still
> there even there conceptually. It is not really true that x86 does
> not need memory barriers, though it doesn't in this case:
>
>
On Thu, Sep 01, 2011 at 06:14:34PM +0200, Paolo Bonzini wrote:
> On 09/01/2011 05:30 PM, Michael S. Tsirkin wrote:
> >>> The virtio code already has memory barrier wmb() macros in the code.
> >>> However they are was defined as no-ops. The comment claims that real
> >>> barriers are not necessa
On Thu, Sep 01, 2011 at 09:56:25AM +0200, Paolo Bonzini wrote:
> On 09/01/2011 09:37 AM, Sasha Levin wrote:
> >>> -#define wmb() __asm__ __volatile__("": : :"memory")
> >>> + /* TODO: we may also need rmb()s. It hasn't bitten us yet, but.. */
> >>> + #define wmb() __sync_synchronize()
> >
> >Th
On Thu, Sep 01, 2011 at 08:47:49AM +0200, Paolo Bonzini wrote:
> On 09/01/2011 08:09 AM, David Gibson wrote:
> >The patch defines wmb() as __sync_synchronize(), a cross platform memory
> >barrier primitive available in sufficiently recent gcc versions (gcc 4.2
> >and after?). If we care about olde
> > > Why not limit the change to ppc then?
> >
> > Because the bug is masked by the x86 memory model, but it is still
> > there even there conceptually. It is not really true that x86 does
> > not need memory barriers, though it doesn't in this case:
> >
> > http://bartoszmilewski.wordpress.com/20
On Thu, Sep 01, 2011 at 06:14:34PM +0200, Paolo Bonzini wrote:
> On 09/01/2011 05:30 PM, Michael S. Tsirkin wrote:
> >>> The virtio code already has memory barrier wmb() macros in the code.
> >>> However they are was defined as no-ops. The comment claims that real
> >>> barriers are not necessa
On 09/01/2011 05:30 PM, Michael S. Tsirkin wrote:
> The virtio code already has memory barrier wmb() macros in the code.
> However they are was defined as no-ops. The comment claims that real
> barriers are not necessary because the code does not run concurrent.
> However, with kvm and io-th
On Thu, Sep 01, 2011 at 04:09:49PM +1000, David Gibson wrote:
> The virtio code already has memory barrier wmb() macros in the code.
> However they are was defined as no-ops. The comment claims that real
> barriers are not necessary because the code does not run concurrent.
> However, with kvm and
On 09/01/2011 09:37 AM, Sasha Levin wrote:
> -#define wmb() __asm__ __volatile__("": : :"memory")
> + /* TODO: we may also need rmb()s. It hasn't bitten us yet, but.. */
> + #define wmb() __sync_synchronize()
That asm directive also implicitly provided a compiler barrier, I could
On Thu, 2011-09-01 at 10:37 +0300, Sasha Levin wrote:
> On Thu, 2011-09-01 at 16:09 +1000, David Gibson wrote:
> > The virtio code already has memory barrier wmb() macros in the code.
> > However they are was defined as no-ops. The comment claims that real
> > barriers are not necessary because th
On Thu, 2011-09-01 at 16:09 +1000, David Gibson wrote:
> The virtio code already has memory barrier wmb() macros in the code.
> However they are was defined as no-ops. The comment claims that real
> barriers are not necessary because the code does not run concurrent.
> However, with kvm and io-thr
On 09/01/2011 08:09 AM, David Gibson wrote:
The patch defines wmb() as __sync_synchronize(), a cross platform memory
barrier primitive available in sufficiently recent gcc versions (gcc 4.2
and after?). If we care about older gccs then this patch will need to
be updated with some sort of fallbac
The virtio code already has memory barrier wmb() macros in the code.
However they are was defined as no-ops. The comment claims that real
barriers are not necessary because the code does not run concurrent.
However, with kvm and io-thread enabled, this is not true and this qemu
code can indeed run
32 matches
Mail list logo
