From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 22 Nov 2011 18:36:37 +0000 Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu Message-Id: <4ECBEBB5.9040500@freescale.com> List-Id: References: <1321955703-1628-1-git-send-email-yu.liu@freescale.com> In-Reply-To: <1321955703-1628-1-git-send-email-yu.liu@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org On 11/22/2011 05:27 AM, Alexander Graf wrote: > > > > > On 22.11.2011, at 12:19, Liu Yu-B13201 wrote: > >> >> >>> -----Original Message----- >>> From: Alexander Graf [mailto:agraf@suse.de] >>> Sent: Tuesday, November 22, 2011 7:14 PM >>> To: Liu Yu-B13201 >>> Cc: ; Liu Yu-B13201 >>> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu >>> >>> >>> On 22.11.2011, at 10:55, Liu Yu 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. Or just always use the supervisor version of SPRG4-7 for kernel access, whether reading or writing -- this should always trap in PR-mode. -Scott