Re: [PATCH v4 0/4] KVM: arm64: Fix underallocation of storage for SVE state

[Fuad Tabba]

Hi,

On Fri, 6 Sept 2024 at 19:03, Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> On Fri, Sep 06, 2024 at 05:14:09PM +0100, Fuad Tabba wrote:
> > On Fri, 6 Sept 2024 at 17:10, Mark Brown <broonie@xxxxxxxxxx> wrote:
> > > On Fri, Sep 06, 2024 at 04:35:29PM +0100, Fuad Tabba wrote:
>
> > > > Yes, but that's not really the issue here, unless I'm missing
> > > > something else. The issue is that pKVM needs to store the host's SVE
> > > > state too, to be able to restore it. So hiding non-symmetrically
> > > > supported VLs for the guests shouldn't be relevant.
>
> > > If the host kernel is also running at EL1 and it's only the hypervisor
> > > running at EL2 then the hypervisor can control the VLs that the host
> > > kernel is able to access?
>
> > Yes it can. But do we want to impose limits on host VLs when running
> > pKVM that might not exist without pKVM?
>
> I mean, at the minute the host kernel will just not configure any
> non-shared VLs so pKVM isn't making a difference anyway.  Even when we
> add kernel mode SVE usage kernel mode FP is preemptable and schedulable
> so we'd not likely want to use non-shared VLs there either.  If someone
> ever felt moved to add support for using any non-shared VLs the most
> likely usage would be for userspace and we'd constrain any tasks using
> SVE to the cores that support their VLs similar to how we handle CPUs
> with no 32 bit support.  Hopefully the scheduler would cope well with
> that.
>
> > Although AFAIK, such hardware doesn't exist in practice, the reason we
> > went down this rabbit hole from the beginning was to ensure that we
> > wouldn't run into problems if it were to happen.
>
> Yes, it's not an issue with any presently known hardware - the issue is
> leaving nasty surprises should someone build it rather than anything
> immediately practical.  Ideally they won't.
>
> My general feeling is that it would have been perfectly fine for pKVM to
> enforce what the host kernel wants to do anyway, if we ever do add
> support for using asymmetric VLs and care about doing so on a system
> running pKVM then dealing with pKVM imposed limits at that time seems
> more than reasonable.  It probably wouldn't be the largest part of the
> work.  Equally we now have the code so we may as well use it?  It's not
> imposing huge overheads.

>From pKVM, this would work and other than the potential for future
support for using asymmetric VLs, I don't really see a problem. Much
of the complexity was an attempt not to make pKVM more restrictive
than other modes.

Cheers,
/fuad