On Mon, May 13, 2019 at 03:07:26PM +0100, Andrew Jones wrote:
> On Mon, May 13, 2019 at 01:43:56PM +0100, Dave Martin wrote:
> > On Sun, May 12, 2019 at 09:36:16AM +0100, Andrew Jones wrote:
> > > These are the SVE equivalents to kvm_arch_get/put_fpsimd.
> > >
> > > Signed-off-by: Andrew Jones <drjo...@redhat.com>
> > > ---
> > > target/arm/kvm64.c | 127 +++++++++++++++++++++++++++++++++++++++++++--
> > > 1 file changed, 123 insertions(+), 4 deletions(-)
> >
> > [...]
> >
> > > +static int kvm_arch_put_sve(CPUState *cs)
> > > +{
> > > + ARMCPU *cpu = ARM_CPU(cs);
> > > + CPUARMState *env = &cpu->env;
> > > + struct kvm_one_reg reg;
> > > + int n, ret;
> > > +
> > > + for (n = 0; n < KVM_ARM64_SVE_NUM_ZREGS; n++) {
> > > + uint64_t *q = aa64_vfp_qreg(env, n);
> > > +#ifdef HOST_WORDS_BIGENDIAN
> > > + uint64_t d[ARM_MAX_VQ * 2];
> > > + int i;
> > > + for (i = 0; i < cpu->sve_max_vq * 2; i++) {
> > > + d[i] = q[cpu->sve_max_vq * 2 - 1 - i];
> > > + }
> > > + reg.addr = (uintptr_t)d;
> > > +#else
> > > + reg.addr = (uintptr_t)q;
> > > +#endif
> > > + reg.id = KVM_REG_ARM64_SVE_ZREG(n, 0);
> >
> > Will this silently go wrong if more than one slice is required (i.e.,
> > the register size grows beyond 8192 bits?)
>
> Yeah, I could probably implement the slice loop now and add a
> function that returns 1 (for now) like your vcpu_sve_slices()
> function in KVM. I'll do that for v2.
Or just add a sanity check that the vector length is <= 2048 bits.
Support for larger vectors is untestable for now, since the kernel
doesn't support that and would never expose it.
On that point, could TCG easily be made to expose a larger vector length
to the kernel? I'd be interested to see what happened.
The kernel should warn and hide the larger vector lengths from KVM,
but I've not been able to test that.
It's only worth trying this out if the hacks to QEMU to enable testing
this were pretty trivial, though.
Cheers
---Dave
