qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [Qemu-devel] [PATCH 11/13] target/arm/cpu64: max cpu: Int


From: Andrew Jones
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH 11/13] target/arm/cpu64: max cpu: Introduce sve-vls-map
Date: Mon, 13 May 2019 14:30:23 +0200
User-agent: NeoMutt/20180716

On Mon, May 13, 2019 at 12:26:36PM +0100, Dave Martin wrote:
> On Sun, May 12, 2019 at 09:36:22AM +0100, Andrew Jones wrote:
> > Introduce another cpu property to control SVE vector lengths,
> > sve-vls-map, which allows the user to explicitly select the
> > set of vector lengths the guest can use. The map must conform
> > to QEMU's limits and architectural constraints, checked when
> > the property is set. Inconsistencies with sve-max-vq are also
> > checked. The bit number of a set bit in the map represents the
> > allowed vector length in number of quadwords.
> > 
> > Note, as the map is implemented with a single 64-bit word we
> > currently only support up to 8192-bit vectors. As QEMU and
> > KVM only support up to 2048-bit vectors then this sufficient
> > now, and probably for some time. Extending the bitmap beyond
> > a single word will likely require changing the property to
> > a string and adding yet another parser to QEMU.
> > 
> > Signed-off-by: Andrew Jones <address@hidden>
> > ---
> >  target/arm/cpu.c     |  4 +++
> >  target/arm/cpu.h     |  3 ++
> >  target/arm/cpu64.c   | 70 +++++++++++++++++++++++++++++++++++++++++---
> >  target/arm/helper.c  | 10 ++++++-
> >  target/arm/monitor.c |  9 ++++--
> >  5 files changed, 88 insertions(+), 8 deletions(-)
> > 
> 
> [...]
> 
> > diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> > index 8292d547e8f9..f0d0ce759ba8 100644
> > --- a/target/arm/cpu.h
> > +++ b/target/arm/cpu.h
> > @@ -920,6 +920,9 @@ struct ARMCPU {
> >  
> >      /* Used to set the maximum vector length the cpu will support.  */
> >      uint32_t sve_max_vq;
> > +
> > +    /* Each bit represents a supported vector length of (bitnum * 16) 
> > bytes */
> > +    uint64_t sve_vls_map;
> 
> Just to be clear, the representation here is different from the
> representation in KVM_REG_ARM64_SVE_VLS?
> 
> In the latter, bit n represents vector length ((n + 1) * 16) bytes.

KVM also uses bitnum * 16. bitnum is the the bit number, not the shift.
So you can't have bitnum=0. 'n' must be a shift, as it would need to
allow zero in order to represent KVM_ARM64_SVE_VQ_MIN.

> 
> (QEMU is free to choose its own internal representation, naturally.)
> 
> [...]
> 
> > diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> 
> [...]
> 
> > +static void cpu_set_sve_vls_map(Object *obj, Visitor *v, const char *name,
> > +                                void *opaque, Error **errp)
> > +{
> > +    ARMCPU *cpu = ARM_CPU(obj);
> > +    Error *err = NULL;
> > +    uint64_t mask = ~(BIT_MASK(ARM_MAX_VQ - 1) - 1);
> > +    int i;
> > +
> > +    visit_type_uint64(v, name, &cpu->sve_vls_map, errp);
> > +
> > +    if (!err) {
> > +        if (cpu->sve_vls_map == 0) {
> > +            error_setg(&err, "SVE vector length map cannot be zero");
> 
> Maybe say "empty" here, since the map represents a set?

Empty does sound better when considering the map represents a set, but
the user will be inputting a number for the map, so zero will be what
they attempted to input.

> 
> (But it this is just for debug rather than reporting errors to the user,
> it probably doesn't matter much.)

I'm also not too worried about which term we use, so I'm happy to change
it if you'd like.

> 
> [...]
> 
> > diff --git a/target/arm/helper.c b/target/arm/helper.c
> > index 1e6eb0d0f360..bedec1ea0b27 100644
> > --- a/target/arm/helper.c
> > +++ b/target/arm/helper.c
> > @@ -5254,12 +5254,20 @@ uint32_t sve_zcr_len_for_el(CPUARMState *env, int 
> > el)
> >  static void zcr_write(CPUARMState *env, const ARMCPRegInfo *ri,
> >                        uint64_t value)
> >  {
> > +    ARMCPU *cpu = arm_env_get_cpu(env);
> >      int cur_el = arm_current_el(env);
> >      int old_len = sve_zcr_len_for_el(env, cur_el);
> >      int new_len;
> >  
> >      /* Bits other than [3:0] are RAZ/WI.  */
> > -    raw_write(env, ri, value & 0xf);
> > +    value &= 0xf;
> 
> You might want to sanity-check that the max vq you configured for the
> vcpu is <= 16 here.

It's already checked by the cpu property set function at input time.

> 
> > +
> > +    if (value && !(BIT_MASK(value) & cpu->sve_vls_map)) {
> > +        uint64_t map = cpu->sve_vls_map & (BIT_MASK(value) - 1);
> > +        value = arm_cpu_fls64(map) - 1;
> > +    }
> > +
> > +    raw_write(env, ri, value);
> 
> [...]
> 
> Cheers
> ---Dave
> 

Thanks,
drew



reply via email to

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