From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Subject: Re: [PATCH 2/2] KVM: PPC: Book3S: Implement floating-point state get/set functions Date: Fri, 14 Sep 2012 11:36:37 +1000 Message-ID: <20120914013636.GA31335@drongo> References: <20120912001719.GE32642@bloggs.ozlabs.ibm.com> <20120912001922.GG32642@bloggs.ozlabs.ibm.com> <716EE2F4-D016-4009-A11A-0866C1A75995@suse.de> <20120913235816.GB14036@bloggs.ozlabs.ibm.com> <9E858BF2-180D-48D3-AD0D-89ACB9436554@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Alexander Graf Return-path: Content-Disposition: inline In-Reply-To: <9E858BF2-180D-48D3-AD0D-89ACB9436554@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, Sep 14, 2012 at 02:03:15AM +0200, Alexander Graf wrote: > > Yup, Considering how different the FPU state on differnet ppc cores is, I'd be more happy with shoving it into something that allows for more dynamic control. Otherwise we'd end up with yet another struct sregs that can contain SPE registers, altivec, and a dozen additions to it :). > > Please just use one_reg for all of the register synchronization you want to add, unless there's a compelling reason to do it differently. It will make our live a lot easier in the future. If we need to transfer too much data and actually run into performance trouble, we can always add a GET_MANY_REG ioctl. It just seems perverse to ignore the existing interface that every other architecture uses, and instead do something unique that is actually slower, but whatever... Paul.