From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 03 Jul 2013 18:36:15 +0000 Subject: Re: [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Message-Id: <1372876575.8183.137@snotra> List-Id: References: <1372855359-13452-1-git-send-email-mihai.caraman@freescale.com> <1372855359-13452-5-git-send-email-mihai.caraman@freescale.com> <300B73AA675FCE4A93EB4FC1D42459FF0A2A3D41@039-SN2MPN1-013.039d.mgd.msft.net> <300B73AA675FCE4A93EB4FC1D42459FF0A2A3E93@039-SN2MPN1-013.039d.mgd.msft.net> <098F899F-54BF-4172-958B-C52C015F5142@suse.de> In-Reply-To: <098F899F-54BF-4172-958B-C52C015F5142@suse.de> (from agraf@suse.de on Wed Jul 3 12:07:30 2013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Caraman Mihai Claudiu-B02008 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" On 07/03/2013 12:07:30 PM, Alexander Graf wrote: > > On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote: > > >>>> Do we need to do this even when the guest doesn't use Altivec? > Can't > >> we > >>>> just load it on demand then once we fault? This code path really > >> should > >>>> only be a prefetch enable when MSR_VEC is already set in guest > >> context. > >>> > >>> No we can't, read 6/6. > >> > >> So we have to make sure we're completely unlazy when it comes to a > KVM > >> guest. Are we? > > > > Yes, because MSR[SPV] is under its control. > > Oh, sure, KVM wants it unlazy. That part is obvious. But does the > kernel always give us unlazyness? The way I read the code, process.c > goes lazy when !CONFIG_SMP. > > So the big question is why we're manually enforcing FPU giveup, but > not Altivec giveup? One of the 2 probably is wrong :). Why do you think we're not enforcing it for Altivec? Is there some specific piece of code you're referring to that is different in this regard? -Scott