On Thu, Apr 25, 2019 at 04:04:36PM +0100, Alex Bennée wrote:
>
> Dave Martin <Dave.Martin@xxxxxxx> writes:
>
> > On Thu, Apr 25, 2019 at 01:30:29PM +0100, Alex Bennée wrote:
> >>
> >> Dave Martin <Dave.Martin@xxxxxxx> writes:
> >>
> >> > Currently, the way error codes are generated when processing the
> >> > SVE register access ioctls in a bit haphazard.
> >> >
> >> > This patch refactors the code so that the behaviour is more
> >> > consistent: now, -EINVAL should be returned only for unrecognised
> >> > register IDs or when some other runtime error occurs. -ENOENT is
> >> > returned for register IDs that are recognised, but whose
> >> > corresponding register (or slice) does not exist for the vcpu.
> >> >
> >> > To this end, in {get,set}_sve_reg() we now delegate the
> >> > vcpu_has_sve() check down into {get,set}_sve_vls() and
> >> > sve_reg_to_region(). The KVM_REG_ARM64_SVE_VLS special case is
> >> > picked off first, then sve_reg_to_region() plays the role of
> >> > exhaustively validating or rejecting the register ID and (where
> >> > accepted) computing the applicable register region as before.
> >> >
> >> > sve_reg_to_region() is rearranged so that -ENOENT or -EPERM is not
> >> > returned prematurely, before checking whether reg->id is in a
> >> > recognised range.
> >> >
> >> > -EPERM is now only returned when an attempt is made to access an
> >> > actually existing register slice on an unfinalized vcpu.
> >> >
> >> > Fixes: e1c9c98345b3 ("KVM: arm64/sve: Add SVE support to register access ioctl interface")
> >> > Fixes: 9033bba4b535 ("KVM: arm64/sve: Add pseudo-register for the guest's vector lengths")
> >> > Suggested-by: Andrew Jones <drjones@xxxxxxxxxx>
> >> > Signed-off-by: Dave Martin <Dave.Martin@xxxxxxx>
> >> > Reviewed-by: Andrew Jones <drjones@xxxxxxxxxx>
> >
> > [...]
> >
> >> > @@ -335,25 +344,30 @@ static int sve_reg_to_region(struct sve_state_reg_region *region,
> >> > /* Verify that we match the UAPI header: */
> >> > BUILD_BUG_ON(SVE_NUM_SLICES != KVM_ARM64_SVE_MAX_SLICES);
> >> >
> >> > - if ((reg->id & SVE_REG_SLICE_MASK) > 0)
> >> > - return -ENOENT;
> >> > -
> >> > - vq = sve_vq_from_vl(vcpu->arch.sve_max_vl);
> >> > -
> >> > reg_num = (reg->id & SVE_REG_ID_MASK) >> SVE_REG_ID_SHIFT;
> >> >
> >> > if (reg->id >= zreg_id_min && reg->id <= zreg_id_max) {
> >> > + if (!vcpu_has_sve(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
> >> > + return -ENOENT;
> >> > +
> >> > + vq = sve_vq_from_vl(vcpu->arch.sve_max_vl);
> >> > +
> >> > reqoffset = SVE_SIG_ZREG_OFFSET(vq, reg_num) -
> >> > SVE_SIG_REGS_OFFSET;
> >> > reqlen = KVM_SVE_ZREG_SIZE;
> >> > maxlen = SVE_SIG_ZREG_SIZE(vq);
> >> > } else if (reg->id >= preg_id_min && reg->id <= preg_id_max) {
> >> > + if (!vcpu_has_sve(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
> >> > + return -ENOENT;
> >> > +
> >> > + vq = sve_vq_from_vl(vcpu->arch.sve_max_vl);
> >> > +
> >>
> >> I suppose you could argue for a:
> >>
> >> if (reg->id >= zreg_id_min && reg->id <= preg_id_max) {
> >> if (!vcpu_has_sve(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
> >> return -ENOENT;
> >>
> >> vq = sve_vq_from_vl(vcpu->arch.sve_max_vl);
> >>
> >> if (reg->id <= zreg_id_max) {
> >> reqoffset = SVE_SIG_ZREG_OFFSET(vq, reg_num) -
> >> SVE_SIG_REGS_OFFSET;
> >> reqlen = KVM_SVE_ZREG_SIZE;
> >> maxlen = SVE_SIG_ZREG_SIZE(vq);
> >> } else {
> >> reqoffset = SVE_SIG_PREG_OFFSET(vq, reg_num) -
> >> SVE_SIG_REGS_OFFSET;
> >> reqlen = KVM_SVE_PREG_SIZE;
> >> maxlen = SVE_SIG_PREG_SIZE(vq);
> >> }
> >> } else {
> >> return -EINVAL;
> >> }
> >>
> >> but only for minimal DRY reasons.
> >
> > Agreed, but that bakes in another assumption: that the ZREG and PREG ID
> > ranges are contiguous.
>
> Ahh I'd misread:
>
> /* reg ID ranges for P- registers and FFR (which are contiguous) */
>
> However these are defined in the UABI:
>
> /* Z- and P-regs occupy blocks at the following offsets within this range: */
> #define KVM_REG_ARM64_SVE_ZREG_BASE 0
> #define KVM_REG_ARM64_SVE_PREG_BASE 0x400
> #define KVM_REG_ARM64_SVE_FFR_BASE 0x600
>
> so there position is pretty fixed now right?
Yes. I couldn't really decide how much we consider this a to be
a happy accident.
In hindsight, simply making FFR == "P16" official may have been the
simpler way to go, but it should work whether code explicitly assumes
this or not. As of today, I prefer not to encourage it too much,
but this is more for philosophical than practical reasons.
[...]
Cheers
---Dave
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
