qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]