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

[Mark Brown]

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.

Attachment: signature.asc
Description: PGP signature