> -----Original Message----- > From: kvm-ppc-owner@xxxxxxxxxxxxxxx [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of > Alexander Graf > Sent: Tuesday, November 22, 2011 2:45 PM > To: Wood Scott-B07421 > Cc: Liu Yu-B13201; <kvm-ppc@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu > > > On 22.11.2011, at 19:36, Scott Wood <scottwood@xxxxxxxxxxxxx> wrote: > > > On 11/22/2011 05:27 AM, Alexander Graf wrote: > >> > >> > >> > >> > >> On 22.11.2011, at 12:19, Liu Yu-B13201 <B13201@xxxxxxxxxxxxx> wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Alexander Graf [mailto:agraf@xxxxxxx] > >>>> Sent: Tuesday, November 22, 2011 7:14 PM > >>>> To: Liu Yu-B13201 > >>>> Cc: <kvm-ppc@xxxxxxxxxxxxxxx>; Liu Yu-B13201 > >>>> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu > >>>> > >>>> > >>>> On 22.11.2011, at 10:55, Liu Yu <yu.liu@xxxxxxxxxxxxx> wrote: > >>>> > >>>>> Previously, only primary vcpu get enabled paravirt. > >>>> > >>>> Please fix it the other way around. Thd hypercall is CPU local and > >>>> should stay that way, so we have to call it on each vcpu inside the > >>>> guest. > >>>> > >>> > >>> The guest kernel already use on_each_cpu() But seems it doesn't > >>> work. > >>> The place primary cpu do hypercall is still in early_init where > >>> secondary cpus don't get kicked. > >> > >> Ouch. Then let's go with this approach and > >> > >> a) update the hypercall documentation > >> b) change the guest code to not loop through all cpus > >> c) flush the tlb cache on all vcpus from the hc handler > > > > It's currently only our internal tree that does it from early_init (as > > part of the idle paravirt patch, to avoid races -- though I can't > > recall now what the problematic race is there). It should have been > > changed for the SPRG4-7 paravirt as well. We don't want a secondary > > CPU to take an exception and save something into a paravirt SPRG, but > > read from the hardware SPRG, due to the patching being incomplete. > > > > An alternative would be to still do it after secondaries are up, but > > instead of just doing the hcall in kvm_map_magic_page, all but one cpu > > would be held in a loop with interrupts off until the patching is complete. > > That sounds good. Then they can all do the hcall themselves and contine running. Why do the secondaries need to spin...can they just make the call as the very first thing when coming out of the spin table? Just let the boot CPU do the patching before releasing the secondaries. Stuart -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
