> -----Original Message----- > From: Alexander Graf [mailto:agraf@xxxxxxx] > Sent: Tuesday, November 22, 2011 3:28 PM > To: Yoder Stuart-B08248 > Cc: Wood Scott-B07421; Liu Yu-B13201; <kvm-ppc@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu > > > On 22.11.2011, at 22:11, Yoder Stuart-B08248 wrote: > > > > > > >> -----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. > > That is very subarch-specific, so we'd have to treat e500 different from 440 different from > book3s_32 different from book3s_64 I suppose. > If you want to go through that exercise, it might be worth it. The overall thing would be > easier then at the end of the day - except for the startup code for secondaries. Hmm...not sure which approach makes sense. So to make sure I understand Scott's proposal the sequence would be something like: -after secondaries CPUs are released from spin and can determine they are running under KVM they: -disable interrupts -set a flag indicating they are waiting for paravirt patching to complete -spin in a loop until a flag is set that indicates paravirt patch is complete -make the paravirt hcall -boot CPU -waits for all secondaries to set the 'waiting for paravirt' flag -makes the paravirt hcall -patches the kernel -sets 'paravirt complete' flag Is that basically correct? 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
