Re: [RFC PATCH 16/16] KVM: arm64/sve: Report and enable SVE API extensions for userspace

Dave Martin
2018-08-08T08:30:50Z

On Tue, Aug 07, 2018 at 10:08:28PM +0200, Christoffer Dall wrote:
> On Tue, Aug 07, 2018 at 12:23:45PM +0100, Dave Martin wrote:
> > On Mon, Aug 06, 2018 at 03:41:33PM +0200, Christoffer Dall wrote:

[...]

> > > I'm personally fine with both feature flags and vcpu device ioctls. If
> > > using vcpu device ioctls gives you an obvious way to set attributes
> > > relating to SVE, e.g. the vector length, then I think that's a strong
> > > argument for that approach.
> >
> > There is another option I'm tending towards, which is simply to have
> > a "set vector lengths" ioctl (whether presented as a vcpu device
> > ioctl or a random arch ioctl).
>
> Someone complained once about adding too many arch ioctls because there
> is a limited number space for doing so, but I'm not sure if that was and
> still a valid concern.

I have no strong opinion on this. I may stick with the separate ioctl
approach for the next spin just to reduce the amount of churn, but I'm
not overly committed to it.

> >
> > If that ioctl() fails then SVE support is not available.
> >
> > If it succeeds, it will update its arguments to indicate which
> > vector lengths are enabled (if different).
> >
> > Old userspace, or userspace that doesn't want to use SVE, would
> > not use this ioctl at all.
> >
> > It would also do no harm additionally to advertise this as a
> > capability, though I wonder whether it's necessary to do so (?)
> >
>
> It is customary to expose features via capabilities. I have a vague
> recollection that tools like libvirt negotiate capabilities across
> systems and would need more plumbing to discover features by probing an
> ioctl instead.

OK, fair enough.

Cheers
---Dave