Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Fuad Tabba <tabba@google.com>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	maz@kernel.org, will@kernel.org, qperret@google.com,
	seanjc@google.com, alexandru.elisei@arm.com,
	catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com,
	suzuki.poulose@arm.com, mark.rutland@arm.com, joey.gouly@arm.com,
	rananta@google.com, yuzenghui@huawei.com
Subject: Re: [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode
Date: Fri, 17 May 2024 19:19:00 +0100	[thread overview]
Message-ID: <b73372b3-e032-4afd-a7cd-e08a687b1d3f@sirena.org.uk> (raw)
In-Reply-To: <ZkeUTix0Ojn5eHKP@linux.dev>

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On Fri, May 17, 2024 at 05:30:54PM +0000, Oliver Upton wrote:

> Hmm... Is there any reason why we need to be concerned about preserving
> host SVE state?

> The syscall ABI has it that only the first 128 bits of the vector
> registers are preserved by the kernel, and I see no reason why we
> couldn't apply a similar restriction to KVM_RUN HVCs into EL2. We'd need
> to eagerly flush the vector registers on entry to avoid disclosing guest
> usage of SVE.

> What you have is certainly correct, I just wonder if we're going out of
> our way to save/restore 0's for larger VLs.

Not just larger VLs, there's also the P registers even for 128 bit SVE.

I think it'd be sensible to discard.  A big part of why the host ABI is
like that is that the AAPCS makes the SVE specific state caller
preserved on function calls, with syscalls mirroring that.  This means
that even if the kernel is using FP the HVC would need to be inline in a
function using SVE in order to get any state that needs to be preserved
in there, or there'd need to be some other non-AAPCS thing going on.  We
already ensure that any EL0 state is saved prior to trying to run a VM,
I've not checked the interaction with pKVM here but if there's any
issues I'd hope it's not too difficult to close them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2024-05-17 18:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 13:18 [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 1/7] KVM: arm64: Reintroduce __sve_save_state Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 2/7] KVM: arm64: Specialize deactivate fpsimd/sve traps on guest trap Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 3/7] KVM: arm64: Specialize handling of host fpsimd state on trap Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 4/7] KVM: arm64: Store the maximum sve vector length at hyp Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 5/7] KVM: arm64: Allocate memory at hyp for host sve state in pKVM Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 6/7] KVM: arm64: Eagerly restore host fpsimd/sve " Fuad Tabba
2024-05-17 17:09   ` Oliver Upton
2024-05-20  7:37     ` Fuad Tabba
2024-05-20  8:05       ` Marc Zyngier
2024-05-20  8:53         ` Fuad Tabba
2024-05-20 17:08         ` Oliver Upton
2024-05-17 13:18 ` [PATCH v1 7/7] KVM: arm64: Consolidate initializing the host data's fpsimd_state/sve " Fuad Tabba
2024-05-17 17:30 ` [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode Oliver Upton
2024-05-17 18:19   ` Mark Brown [this message]
2024-05-20  7:35     ` Fuad Tabba
2024-05-20  8:11       ` Marc Zyngier
2024-05-20 17:37         ` Oliver Upton
2024-05-20 17:53           ` Mark Brown
2024-05-20 17:59             ` Fuad Tabba
2024-05-20 17:57           ` Fuad Tabba
2024-05-20 20:53             ` Oliver Upton
2024-05-21 12:27               ` Fuad Tabba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b73372b3-e032-4afd-a7cd-e08a687b1d3f@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=philmd@linaro.org \
    --cc=qperret@google.com \
    --cc=rananta@google.com \
    --cc=seanjc@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox