From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Date: Wed, 3 Jul 2013 13:36:15 -0500 Message-ID: <1372876575.8183.137@snotra> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Caraman Mihai Claudiu-B02008 , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" To: Alexander Graf Return-path: Received: from va3ehsobe005.messaging.microsoft.com ([216.32.180.31]:18285 "EHLO va3outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932660Ab3GCSgU convert rfc822-to-8bit (ORCPT ); Wed, 3 Jul 2013 14:36:20 -0400 In-Reply-To: <098F899F-54BF-4172-958B-C52C015F5142@suse.de> (from agraf@suse.de on Wed Jul 3 12:07:30 2013) Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: 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