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. Paul. -- 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
