From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Subject: Re: [PATCH] kvm/ppc/booke64: fix build breakage from Altivec, and
 disable e6500
Date: Fri, 10 May 2013 14:15:34 -0500
Message-ID: <1368213334.19683.9@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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed
Content-Transfer-Encoding: 8BIT
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	Alexander Graf <agraf@suse.de>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
To: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-db8lp0188.outbound.messaging.microsoft.com ([213.199.154.188]:11609
	"EHLO db8outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1753253Ab3EJTPk convert rfc822-to-8bit
	(ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 10 May 2013 15:15:40 -0400
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF40816A@039-SN2MPN1-013.039d.mgd.msft.net>
	(from B02008@freescale.com on Fri May 10 14:06:53 2013)
Content-Disposition: inline
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.

-Scott