Re: [PATCH v2 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes
On 30/11/2015 18:34, Eduardo Habkost wrote:
> target-i386/cpu.c:ext_save_area uses magic numbers for the xsave
> area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave()
> uses offset macros and bit manipulation to access the xsave area.
> This series changes both to use C structs for those operations.
>
> I still need to figure out a way to write unit tests for the new
> code. Maybe I will just copy and paste the new and old functions,
> and test them locally (checking if they give the same results
> when translating blobs of random bytes).
>
> Changes v1 -> v2:
> * Use uint8_t[8*n] instead of uint64_t[n] for register data
> * Keep the QEMU_BUILD_BUG_ON lines
>
> v1 -> v2 diff below:
>
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 3d1d01e..41f55ef 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -818,7 +818,7 @@ typedef union X86LegacyXSaveArea {
>uint32_t mxcsr;
>uint32_t mxcsr_mask;
>FPReg fpregs[8];
> -uint64_t xmm_regs[16][2];
> +uint8_t xmm_regs[16][16];
>};
>uint8_t data[512];
>} X86LegacyXSaveArea;
> @@ -831,7 +831,7 @@ typedef struct X86XSaveHeader {
>
>/* Ext. save area 2: AVX State */
>typedef struct XSaveAVX {
> -uint64_t ymmh[16][2];
> +uint8_t ymmh[16][16];
>} XSaveAVX;
>
>/* Ext. save area 3: BNDREG */
> @@ -852,12 +852,12 @@ typedef struct XSaveOpmask {
>
>/* Ext. save area 6: ZMM_Hi256 */
>typedef struct XSaveZMM_Hi256 {
> -uint64_t zmm_hi256[16][4];
> +uint8_t zmm_hi256[16][32];
>} XSaveZMM_Hi256;
>
>/* Ext. save area 7: Hi16_ZMM */
>typedef struct XSaveHi16_ZMM {
> -XMMReg hi16_zmm[16];
> +uint8_t hi16_zmm[16][64];
>} XSaveHi16_ZMM;
>
>typedef struct X86XSaveArea {
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 5e7ec70..98249e4 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -1203,6 +1203,43 @@ static int kvm_put_fpu(X86CPU *cpu)
>return kvm_vcpu_ioctl(CPU(cpu), KVM_SET_FPU, );
>}
>
> +#define XSAVE_FCW_FSW 0
> +#define XSAVE_FTW_FOP 1
> +#define XSAVE_CWD_RIP 2
> +#define XSAVE_CWD_RDP 4
> +#define XSAVE_MXCSR 6
> +#define XSAVE_ST_SPACE8
> +#define XSAVE_XMM_SPACE 40
> +#define XSAVE_XSTATE_BV 128
> +#define XSAVE_YMMH_SPACE 144
> +#define XSAVE_BNDREGS 240
> +#define XSAVE_BNDCSR 256
> +#define XSAVE_OPMASK 272
> +#define XSAVE_ZMM_Hi256 288
> +#define XSAVE_Hi16_ZMM416
> +
> +#define XSAVE_BYTE_OFFSET(word_offset) \
> +((word_offset)*sizeof(((struct kvm_xsave*)0)->region[0]))
> +
> +#define ASSERT_OFFSET(word_offset, field) \
> +QEMU_BUILD_BUG_ON(XSAVE_BYTE_OFFSET(word_offset) != \
> + offsetof(X86XSaveArea, field))
> +
> +ASSERT_OFFSET(XSAVE_FCW_FSW, legacy.fcw);
> +ASSERT_OFFSET(XSAVE_FTW_FOP, legacy.ftw);
> +ASSERT_OFFSET(XSAVE_CWD_RIP, legacy.fpip);
> +ASSERT_OFFSET(XSAVE_CWD_RDP, legacy.fpdp);
> +ASSERT_OFFSET(XSAVE_MXCSR, legacy.mxcsr);
> +ASSERT_OFFSET(XSAVE_ST_SPACE, legacy.fpregs);
> +ASSERT_OFFSET(XSAVE_XMM_SPACE, legacy.xmm_regs);
> +ASSERT_OFFSET(XSAVE_XSTATE_BV, header.xstate_bv);
> +ASSERT_OFFSET(XSAVE_YMMH_SPACE, avx_state);
> +ASSERT_OFFSET(XSAVE_BNDREGS, bndreg_state);
> +ASSERT_OFFSET(XSAVE_BNDCSR, bndcsr_state);
> +ASSERT_OFFSET(XSAVE_OPMASK, opmask_state);
> +ASSERT_OFFSET(XSAVE_ZMM_Hi256, zmm_hi256_state);
> +ASSERT_OFFSET(XSAVE_Hi16_ZMM, hi16_zmm_state);
> +
>static int kvm_put_xsave(X86CPU *cpu)
>{
>CPUX86State *env = >env;
> @@ -1239,17 +1276,17 @@ static int kvm_put_xsave(X86CPU *cpu)
>sizeof env->opmask_regs);
>
>for (i = 0; i < CPU_NB_REGS; i++) {
> -X86LegacyXSaveArea *legacy = >legacy;
> -XSaveAVX *avx = >avx_state;
> -XSaveZMM_Hi256 *zmm_hi256 = >zmm_hi256_state;
> -stq_p(>xmm_regs[i][0], env->xmm_regs[i].XMM_Q(0));
> -stq_p(>xmm_regs[i][1], env->xmm_regs[i].XMM_Q(1));
> -stq_p(>ymmh[i][0],env->xmm_regs[i].XMM_Q(2));
> -stq_p(>ymmh[i][1],env->xmm_regs[i].XMM_Q(3));
> -stq_p(_hi256->zmm_hi256[i][0], env->xmm_regs[i].XMM_Q(4));
> -stq_p(_hi256->zmm_hi256[i][1], env->xmm_regs[i].XMM_Q(5));
> -stq_p(_hi256->zmm_hi256[i][2], env->xmm_regs[i].XMM_Q(6));
> -stq_p(_hi256->zmm_hi256[i][3], env->xmm_regs[i].XMM_Q(7));
> +uint8_t *xmm = xsave->legacy.xmm_regs[i];
> +uint8_t *ymmh = xsave->avx_state.ymmh[i];
> +uint8_t *zmmh = xsave->zmm_hi256_state.zmm_hi256[i];
> +stq_p(xmm, env->xmm_regs[i].XMM_Q(0));
> +stq_p(xmm+8, env->xmm_regs[i].XMM_Q(1));
> +stq_p(ymmh,env->xmm_regs[i].XMM_Q(2));
> +stq_p(ymmh+8, env->xmm_regs[i].XMM_Q(3));
> +stq_p(zmmh,
Re: [PATCH v2 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes
On 30/11/2015 18:34, Eduardo Habkost wrote:
> target-i386/cpu.c:ext_save_area uses magic numbers for the xsave
> area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave()
> uses offset macros and bit manipulation to access the xsave area.
> This series changes both to use C structs for those operations.
>
> I still need to figure out a way to write unit tests for the new
> code. Maybe I will just copy and paste the new and old functions,
> and test them locally (checking if they give the same results
> when translating blobs of random bytes).
I think it's easier to use small guests (i.e. kvm-unit-tests) to test
this code.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes
On Tue, Dec 01, 2015 at 11:22:31AM +0100, Paolo Bonzini wrote:
> On 30/11/2015 18:34, Eduardo Habkost wrote:
> > target-i386/cpu.c:ext_save_area uses magic numbers for the xsave
> > area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave()
> > uses offset macros and bit manipulation to access the xsave area.
> > This series changes both to use C structs for those operations.
> >
> > I still need to figure out a way to write unit tests for the new
> > code. Maybe I will just copy and paste the new and old functions,
> > and test them locally (checking if they give the same results
> > when translating blobs of random bytes).
> >
> > Changes v1 -> v2:
> > * Use uint8_t[8*n] instead of uint64_t[n] for register data
> > * Keep the QEMU_BUILD_BUG_ON lines
> >
[...]
> >
> > Eduardo Habkost (3):
> > target-i386: Define structs for layout of xsave area
> > target-i386: Use xsave structs for ext_save_area
> > target-i386: kvm: Use X86XSaveArea struct for xsave save/load
> >
> > target-i386/cpu.c | 18 +++
> > target-i386/cpu.h | 85
> > target-i386/kvm.c | 96
> > +--
> > 3 files changed, 155 insertions(+), 44 deletions(-)
> >
>
> The patches are okay, are you going to rebase them on top of the PKRU
> patches?
I will probably redo the PKRU patches on top of this, to reduce
diff size.
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes
On 01/12/2015 16:25, Eduardo Habkost wrote: > > I think it's easier to use small guests (i.e. kvm-unit-tests) to test > > this code. > > I agree it's easier, but how likely it is to catch bugs in the > save/load code? If the code corrupts a register, we need to > trigger a save/load cycle at the exact moment the guest code is > using that register. Do we have something that helps us > repeatedly save/load CPU state while kvm-unit-tests is running? A vmware magic port read should do that. Put VMPORT_MAGIC in EAX and VMPORT_CMD_GETVERSION in ECX, then do a 32-bit in from port 0x5658. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes
On Tue, Dec 01, 2015 at 04:09:44PM +0100, Paolo Bonzini wrote:
>
>
> On 30/11/2015 18:34, Eduardo Habkost wrote:
> > target-i386/cpu.c:ext_save_area uses magic numbers for the xsave
> > area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave()
> > uses offset macros and bit manipulation to access the xsave area.
> > This series changes both to use C structs for those operations.
> >
> > I still need to figure out a way to write unit tests for the new
> > code. Maybe I will just copy and paste the new and old functions,
> > and test them locally (checking if they give the same results
> > when translating blobs of random bytes).
>
> I think it's easier to use small guests (i.e. kvm-unit-tests) to test
> this code.
I agree it's easier, but how likely it is to catch bugs in the
save/load code? If the code corrupts a register, we need to
trigger a save/load cycle at the exact moment the guest code is
using that register. Do we have something that helps us
repeatedly save/load CPU state while kvm-unit-tests is running?
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
