> -----Original Message-----
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Tuesday, November 22, 2011 3:28 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Liu Yu-B13201; <kvm-ppc@vger.kernel.org>
> 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-ow...@vger.kernel.org
> >> [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf
> >> Sent: Tuesday, November 22, 2011 2:45 PM
> >> To: Wood Scott-B07421
> >> Cc: Liu Yu-B13201; <kvm-ppc@vger.kernel.org>
> >> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu
> >>
> >>
> >> On 22.11.2011, at 19:36, Scott Wood <scottw...@freescale.com> wrote:
> >>
> >>> On 11/22/2011 05:27 AM, Alexander Graf wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 22.11.2011, at 12:19, Liu Yu-B13201 <b13...@freescale.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>>>> Sent: Tuesday, November 22, 2011 7:14 PM
> >>>>>> To: Liu Yu-B13201
> >>>>>> Cc: <kvm-ppc@vger.kernel.org>; Liu Yu-B13201
> >>>>>> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu
> >>>>>>
> >>>>>>
> >>>>>> On 22.11.2011, at 10:55, Liu Yu <yu....@freescale.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
