qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH 7/9] target/arm: Expand vector registers for SVE


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-arm] [PATCH 7/9] target/arm: Expand vector registers for SVE
Date: Thu, 11 Jan 2018 18:58:41 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

* Peter Maydell (address@hidden) wrote:
> On 18 December 2017 at 17:30, Richard Henderson
> <address@hidden> wrote:
> > Change vfp.regs as a uint64_t to vfp.zregs as an ARMVectorReg.
> > The previous patches have made the change in representation
> > relatively painless.
> >
> > Add vfp.pregs as an ARMPredicateReg.  Let FFR be P16 to make
> > it easier to treat it as for any other predicate.
> 
> > diff --git a/target/arm/machine.c b/target/arm/machine.c
> > index a85c2430d3..39f3123b10 100644
> > --- a/target/arm/machine.c
> > +++ b/target/arm/machine.c
> > @@ -50,7 +50,42 @@ static const VMStateDescription vmstate_vfp = {
> >      .minimum_version_id = 3,
> >      .needed = vfp_needed,
> >      .fields = (VMStateField[]) {
> > -        VMSTATE_UINT64_ARRAY(env.vfp.regs, ARMCPU, 64),
> > +        /* For compatibility, store Qn out of Zn here.  */
> > +        /* TODO: store the other quadwords in another subsection,
> > +           along with predicate registers and ZCR_EL[1-3].  */
> 
> I think we should get the migration state stuff right at the point
> where we change the data structure in cpu.h.
> 
> 
> > +        VMSTATE_UINT64_SUB_ARRAY(env.vfp.zregs[0].d, ARMCPU, 0, 2),
> > +        VMSTATE_UINT64_SUB_ARRAY(env.vfp.zregs[1].d, ARMCPU, 0, 2),
> > +        VMSTATE_UINT64_SUB_ARRAY(env.vfp.zregs[2].d, ARMCPU, 0, 2),
> 
> David: does the migration code guarantee that we can split an
> old VMSTATE_UINT64_ARRAY into being a sequence of SUB_ARRAYs
> like this and retain the same on-the-wire format (ie and
> keep migration compat) ?

There's no on-the-wire protocol for this - it's just the array elements,
so as long as the total adds up the same and it's still uint64's
it should work.

Dave

> I suspect we've used this clever trick before elsewhere, but thought
> it better to check...
> 
> thanks
> -- PMM
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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