On Sat, 2012-05-19 at 09:24 +0200, Paolo Bonzini wrote:
> I guess the C11/C++ guys required an isync barrier after either loads or
> stores, because they need to order the load/store vs. code accessing
> other memory. This is not needed in QEMU because all guest accesses go
> through cpu_physical
Il 19/05/2012 00:26, Benjamin Herrenschmidt ha scritto:
>> In theory you would need a memory barrier before the first ld/st and one
>> after the last... considering virtio uses map/unmap, what about leaving
>> map/unmap and ld*_phys/st*_phys as the high performance unsafe API?
>> Then you can add b
On Fri, 2012-05-18 at 10:57 +0200, Paolo Bonzini wrote:
> > I'm still tempted to add barriers in map and unmap as well in the case
> > where they don't bounce to provide consistent semantics here, ie, all
> > accesses done between the map and unmap are ordered vs all previous and
> > subsequent ac
Il 18/05/2012 10:18, Benjamin Herrenschmidt ha scritto:
> On Fri, 2012-05-18 at 08:53 +0200, Paolo Bonzini wrote:
>
>> It depends on what semantics you attach to dma_mb. In my opinion,
>> having a separate barrier for DMA is wrong, because you want the same
>> semantics on all architectures.
>>
>
On Fri, 2012-05-18 at 08:53 +0200, Paolo Bonzini wrote:
> It depends on what semantics you attach to dma_mb. In my opinion,
> having a separate barrier for DMA is wrong, because you want the same
> semantics on all architectures.
>
> The x86 requirements are roughly as follows:
>
> 1) it never
Il 17/05/2012 02:24, Benjamin Herrenschmidt ha scritto:
>> > Also, should I make the barrier conditional to kvm_enabled() ? IE. It's
>> > pointless in full emulation and might actually be a performance hit on
>> > something already quite slow...
> Finally ... something like smp_mb() in qemu will tu
On Thu, 2012-05-17 at 10:07 +1000, Benjamin Herrenschmidt wrote:
.../...
> Also, should I make the barrier conditional to kvm_enabled() ? IE. It's
> pointless in full emulation and might actually be a performance hit on
> something already quite slow...
Finally ... something like smp_mb() in qe
So followup
For those on the list: Anthony and I had a chat and we agree that a
better thing to do is to have all cpu_physical_memory_* accesses to be
ordered in program order from the perspective of the VCPUs. Devices that
have performance critical accesses and want to do home made ordering
On Thu, 2012-05-17 at 07:10 +1000, Benjamin Herrenschmidt wrote:
> I have a long experience with dealing with ordering issues on large SMP
> systems and believe me, anything "fine grained" is really really hard to
> generally get right, and the resulting bugs are really nasty to track
> down and e
On Wed, 2012-05-16 at 14:39 -0500, Anthony Liguori wrote:
> I must confess, I have no idea what PCI et al guarantee with respect to
> ordering. What's nasty about this patch is that you're not just ordering wrt
> device writes/reads, but also with the other VCPUs. I don't suspect this
> would
On 05/15/2012 11:35 PM, Benjamin Herrenschmidt wrote:
+/* HACK: full memory barrier here */
+__sync_synchronize();
I thought you were going to limit this to the TCE iommu?
So, it wasn't my intention to send this one with the rest, but I
forgot to explain that to Ben when he resent.
On Wed, May 16, 2012 at 02:35:38PM +1000, Benjamin Herrenschmidt wrote:
>
> > > >
> > > >+/* HACK: full memory barrier here */
> > > >+__sync_synchronize();
> > >
> > > I thought you were going to limit this to the TCE iommu?
> >
> > So, it wasn't my intention to send this one with the r
> > >
> > >+/* HACK: full memory barrier here */
> > >+__sync_synchronize();
> >
> > I thought you were going to limit this to the TCE iommu?
>
> So, it wasn't my intention to send this one with the rest, but I
> forgot to explain that to Ben when he resent. As the comment
> suggests, t
On Mon, May 14, 2012 at 07:52:15PM -0500, Anthony Liguori wrote:
> On 05/09/2012 11:49 PM, Benjamin Herrenschmidt wrote:
> >From: David Gibson
> >
> >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
On Mon, 2012-05-14 at 19:52 -0500, Anthony Liguori wrote:
> >
> > diff --git a/dma-helpers.c b/dma-helpers.c
> > index 36fa963..4350cdf 100644
> > --- a/dma-helpers.c
> > +++ b/dma-helpers.c
> > @@ -312,6 +312,9 @@ int iommu_dma_memory_rw(DMAContext *dma, dma_addr_t
> > addr,
> > buf +=
On 05/09/2012 11:49 PM, Benjamin Herrenschmidt wrote:
From: David Gibson
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 operat
From: David Gibson
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.
The simplest way for now to address that i
17 matches
Mail list logo
