[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0d18dda8-347a-4cd5-b17f-40c646fc3fab@sirena.org.uk>
Date: Tue, 10 Sep 2024 15:19:20 +0100
From: Mark Brown <broonie@...nel.org>
To: Fuad Tabba <tabba@...gle.com>
Cc: Dave Martin <Dave.Martin@....com>, Marc Zyngier <maz@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kvmarm@...ts.linux.dev
Subject: Re: [PATCH v4 0/4] KVM: arm64: Fix underallocation of storage for
SVE state
On Tue, Sep 10, 2024 at 01:49:37PM +0100, Fuad Tabba wrote:
> On Fri, 6 Sept 2024 at 19:03, Mark Brown <broonie@...nel.org> wrote:
> > 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.
Right, so it's just a question of if we want to use the code that
doesn't impose the limit given that we have it already. I'm throwing a
patch that limits the host VL into CI, should be out today.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists