On Wed, May 16, 2012 at 11:04 AM, Marc Zyngier <marc.zyngier at arm.com> wrote: > On 16/05/12 15:14, Christoffer Dall wrote: >> On Wed, May 16, 2012 at 5:19 AM, Marc Zyngier <marc.zyngier at arm.com> wrote: >>> On 15/05/12 21:36, Christoffer Dall wrote: >>>> On Mon, May 14, 2012 at 9:04 AM, Marc Zyngier <marc.zyngier at arm.com> wrote: >>>>> On a SMP host, the barriers should be upgraded to the inner >>>>> shareable domain, so that the effect of the barrier can be >>>>> observed on other CPUs, in case where the virtual CPU is >>>>> migrated from a physical CPU to another. >>>>> >>>> >>>> nice! >>>> >>>> can you explain me again why we know this will never run on a >>>> two-cluster configuration where we could migrate a VM from one cluster >>>> to another, which would require us to upgrade to the outer shareable >>>> domain? I may be missing something here. >>> >>> For the time being, multi-cluster implementation(big.LITTLE) all have >>> the CCI (Cache Coherent Interconnect), which makes the respective inner >>> domains coherent across clusters. >>> >> >> will that also be the case for all future implementations? would there >> be any cost of upgrading to outer cacheable instead on current >> implementations? > > Probably anything going past the SCU (outer domain) will have a cost, > and I'd avoid it if we can. I'll try to ask questions internally to see > what's the exact impact. > > Actually, the barriers should match the level of upgrading we do in the > stage2 translation. > > (Having a peek at pgtable.h...) > > Humpf... We don't do any. Could be interesting in the UP-on-SMP > scenario. Expect a patch shortly. so we need to do something when we migrate between CPUs in the UP-on-SMP case on the KVM (host) side right? > >> (just trying to make sure that we hint the correct intentions) >> >> come to think of it, perhaps we should have a comment explaining why >> we set all these specific bits? > > Sure. I'll write something. awesome. thanks.
