On 14.09.2012, at 01:58, Paul Mackerras wrote: > On Fri, Sep 14, 2012 at 01:30:51AM +0200, Alexander Graf wrote: >> >> On 12.09.2012, at 02:19, Paul Mackerras wrote: >> >>> Currently the KVM_GET_FPU and KVM_SET_FPU ioctls return an EOPNOTSUPP >>> error on powerpc. This implements them for Book 3S processors. Since >>> those processors have more than just the 32 basic floating-point >>> registers, this extends the kvm_fpu structure to have space for the >>> additional registers -- the 32 vector registers (128 bits each) for >>> VMX/Altivec and the 32 additional 64-bit registers that were added >>> on POWER7 for the vector-scalar extension (VSX). It also adds a >>> `valid' field, which is a bitmap indicating which elements contain >>> valid data. >>> >>> The layout of the floating-point register data in the vcpu struct is >>> mostly the same between different flavors of KVM on Book 3S processors, >>> but the set of supported registers may differ depending on what the >>> CPU hardware supports and how much is emulated. Therefore we have >>> a flavor-specific function to work out which set of registers to >>> supply for the get function. >>> >>> On POWER7 processors using the Book 3S HV flavor of KVM, we save the >>> standard floating-point registers together with their corresponding >>> VSX extension register in the vcpu->arch.vsr[] array, since each >>> pair can be loaded or stored with one instruction. This is different >>> to other flavors of KVM, and to other processors (i.e. PPC970) with >>> HV KVM, which store the standard FPRs in vcpu->arch.fpr[]. To cope >>> with this, we use the kvmppc_core_get_fpu_valid() and >>> kvmppc_core_set_fpu_valid() functions to sync between the arch.fpr[] >>> and arch.vsr[] arrays as needed. >>> >>> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx> >> >> Any reason to not use ONE_REG here? > > Just consistency with x86 -- they have an xmm[][] field in their > struct kvm_fpu which looks like it contains their vector state. 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. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
