On Wed, May 16, 2012 at 12:06 PM, Marc Zyngier <marc.zyngier at arm.com> wrote: > On 16/05/12 16:46, Christoffer Dall wrote: >> 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? > > Yes, we do, though the best thing to do is probably to just set SH[1:0] > to 0b11 in the stage2 page tables, in order to upgrade the shareability > of the guest to the inner domain. That way, nothing to be done at switch > time, the cache should be maintained in a consistent state by the HW. > > I posted a patch a few minutes ago to fix this issue. > yeah, only saw it after I read your first message. That's a nice solution. Thanks for explaining.
