From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH] kvm/ppc/booke64: fix build breakage from Altivec, and disable e6500 Date: Thu, 30 May 2013 16:52:45 -0500 Message-ID: <1369950765.14679.20@snotra> References: <1368155698-15784-1-git-send-email-scottwood@freescale.com> <300B73AA675FCE4A93EB4FC1D42459FF3FE2FA@039-SN2MPN1-011.039d.mgd.msft.net> <0FD00883-6578-4AE0-A8A6-AAC6FD050870@suse.de> <300B73AA675FCE4A93EB4FC1D42459FF4059B5@039-SN2MPN1-013.039d.mgd.msft.net> <1368207728.19683.2@snotra> <300B73AA675FCE4A93EB4FC1D42459FF408089@039-SN2MPN1-013.039d.mgd.msft.net> <1368210193.19683.6@snotra> <300B73AA675FCE4A93EB4FC1D42459FF40816A@039-SN2MPN1-013.039d.mgd.msft.net> <1368213334.19683.9@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Caraman Mihai Claudiu-B02008 , Alexander Graf , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" To: Scott Wood Return-path: In-Reply-To: <1368213334.19683.9@snotra> (from scottwood@freescale.com on Fri May 10 14:15:34 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/10/2013 02:15:34 PM, Scott Wood wrote: > On 05/10/2013 02:06:53 PM, Caraman Mihai Claudiu-B02008 wrote: >> > > > I didn't see Tiejun's patch... My goal was just to fix the >> build >> > > break >> > > > without exposing problems, and to encourage a patch to fix it >> > > properly >> > > > to happen sooner rather than later. With Tiejun's patch, >> which is >> > > > similar to mine except that it doesn't disable e6500 support, >> a user >> > > > could BUG() the kernel by forcing an Altivec exception in a >> guest. >> > > I >> > > > didn't want to go further down the road of adding reflectors >> for >> > > those >> > > > exceptions, which could make it look like the problem was >> dealt with >> > > > even though it's still not done. >> > > >> > > I agree it's quite annoying to hit a build breakage. Reflection >> is not >> > > a proper solution for this problem (though we will require it >> later) >> > > but program exception injection looks feasible as a simple fix. >> > >> > Program exception injection still doesn't deal with state >> corruption. >> >> Yes but it's not critical for this particular case since nobody is >> able >> to effectively use that state via altivec instructions. Leaking state >> however can be a real issue. > > Depending on guest behavior it could look like things are working > even though they aren't (e.g. a guest just enables MSR[VEC] and uses > altivec instructions, not relying on exceptions). This really isn't > worth spending a lot of time debating... Once Altivec is fixed > properly (you said that'd be soon, right?), we can add e6500 back to > the list. Am I going to see an Altivec patch soon, or should I ask Gleb to take this patch instead? -Scott