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. The only downside here would be that it wastes a few cycles because the spinning needs to happen somewhere. Too bad ppc doesn't have mwait ;) > > Or just always use the supervisor version of SPRG4-7 for kernel access, > whether reading or writing -- this should always trap in PR-mode. No, halting all other cpus sounds better. Alex > -- 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
