[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [for-2.6 PATCH 1/3] target-i386: Define structs for lay
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [for-2.6 PATCH 1/3] target-i386: Define structs for layout of xsave area |
Date: |
Mon, 30 Nov 2015 12:48:41 -0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Mon, Nov 30, 2015 at 12:18:33PM +0100, Paolo Bonzini wrote:
> On 28/11/2015 20:56, Eduardo Habkost wrote:
> > +/* Ext. save area 2: AVX State */
> > +typedef struct XSaveAVX {
> > + uint64_t ymmh[16][2];
> > +} XSaveAVX;
> > +
>
> Because this is always little endian, I would write it as uint8_t[16][16].
The main reason I used uint64_t was to allow the put/save code to
simply use field[0], field[1], field[2] instead of field,
field+8, field+16. But I think your suggestion makes sense: the
fact that we load/save the register data in 8-byte chunks in
kvm_{get,put}_xsave() has nothing to do with the layout of the
data itself (so it doesn't need to be encoded in the struct
definition).
>
> > +/* Ext. save area 6: ZMM_Hi256 */
> > +typedef struct XSaveZMM_Hi256 {
> > + uint64_t zmm_hi256[16][4];
> > +} XSaveZMM_Hi256;
>
> Same here (uint8_t[16][32]).
>
> > +/* Ext. save area 7: Hi16_ZMM */
> > +typedef struct XSaveHi16_ZMM {
> > + XMMReg hi16_zmm[16];
> > +} XSaveHi16_ZMM;
>
> This is uint8_t[16][64] or uint64_t[16][8].
While writing this series, I had a version that redefined the
XMMReg, YMMReg, ZMMReg structs with the correct sizes, and reused
them for ymmh, zmm_hi256, and hi16_zmm. I still planned to
propose that later. You don't think it would make sense?
--
Eduardo