From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
kvmarm@lists.linux.dev, 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, broonie@kernel.org,
joey.gouly@arm.com, rananta@google.com, smostafa@google.com
Subject: Re: [PATCH v4 01/30] KVM: arm64: Initialize the kvm host data's fpsimd_state pointer in pKVM
Date: Mon, 13 May 2024 10:51:32 +0100 [thread overview]
Message-ID: <86y18em44b.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTw9sBodDrVyJk7SmJLO29N_oYK611=uOHRO7Z9+0bVOEA@mail.gmail.com>
On Sun, 12 May 2024 16:46:51 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> Hi Oliver
>
> On Sat, May 11, 2024 at 7:15 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > On Fri, May 10, 2024 at 09:00:54AM +0100, Fuad Tabba wrote:
> >
> > [...]
> >
> > > > > For protected VMs, we don't want to lazily save/restore the host's
> > > > > fpsimd state, because that could leak information to the host that the
> > > > > protected guest is using fpsimd. Therefore, for protected VMs, the
> > > > > host fpsimd state is maintained (saved/restored) in hyp (at EL2),
> > > > > without the host needing to know or do anything about it.
> >
> > I'm a bit confused by this statement. Isn't pKVM downstream lazily
> > managing fpsimd state on behalf of the host for protected guests? IOW,
> > don't we return to the host with traps enabled at EL2 and load state
> > after the trap?
>
> Sorry, I got my wires crossed between fpsimd and sve. It's the sve
> state that is restored eagerly, rather than rely on the
> TIF_FOREIGN_FPSTATE as in other KVM modes.
>
> > > > But I think that's a regression from the current status. It looks like
> > > > now that the state is really private to EL2, nothing will restore the
> > > > FP context on exit, while this was the case before we reworked this.
> > > >
> > > > It'd be good to plug this in 6.10, as this is a regression.
> > >
> > > You're right. I'll send a patch to fix this.
> >
> > I'd be fine with a hack that *eagerly* saves/restores the fpsimd state
> > on every exit in protected mode for the time being. Not great, but
> > obviously correct and its not like protected mode is very useful
> > upstream to begin with.
>
> I think I have a solution that would maintain the existing behavior
> for non-protected VMs in protected mode, i.e., lazy handling. I just
> want to tidy up the code a bit more, run it through a few more fpsimd
> and sve stress tests, and send the patches.
For the record, I don't think it is worth special-casing non-protected
VMs under pKVM. If eager save/restore is what pKVM needs to ensure
protection, then this should equally apply to non-protected VMs.
Having a single behaviour for a given host mode is hugely beneficial
from a maintenance PoV.
What *could* be done as an optimisation is to make the restore lazy
for *everything* by trapping the host access to the FP state (similar
to what we do for guests, funnily enough).
But I see this only as an optimisation, not as a functional
requirement.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-05-13 9:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 15:05 [PATCH v4 00/30] KVM: arm64: Preamble for pKVM Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 01/30] KVM: arm64: Initialize the kvm host data's fpsimd_state pointer in pKVM Fuad Tabba
2024-05-09 14:09 ` Zenghui Yu
2024-05-09 17:46 ` Fuad Tabba
2024-05-10 2:39 ` Zenghui Yu
2024-05-10 6:44 ` Fuad Tabba
2024-05-10 7:59 ` Marc Zyngier
2024-05-10 8:00 ` Fuad Tabba
2024-05-10 10:49 ` Zenghui Yu
2024-05-11 18:15 ` Oliver Upton
2024-05-12 15:46 ` Fuad Tabba
2024-05-13 9:51 ` Marc Zyngier [this message]
2024-04-23 15:05 ` [PATCH v4 02/30] KVM: arm64: Move guest_owns_fp_regs() to increase its scope Fuad Tabba
2024-05-01 14:16 ` Mark Brown
2024-04-23 15:05 ` [PATCH v4 03/30] KVM: arm64: Refactor checks for FP state ownership Fuad Tabba
2024-05-01 14:17 ` Mark Brown
2024-04-23 15:05 ` [PATCH v4 04/30] KVM: arm64: Do not re-initialize the KVM lock Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 05/30] KVM: arm64: Issue CMOs when tearing down guest s2 pages Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 06/30] KVM: arm64: Avoid BUG-ing from the host abort path Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 07/30] KVM: arm64: Check for PTE validity when checking for executable/cacheable Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 08/30] KVM: arm64: Avoid BBM when changing only s/w bits in Stage-2 PTE Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 09/30] KVM: arm64: Support TLB invalidation in guest context Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 10/30] KVM: arm64: Rename __tlb_switch_to_{guest,host}() in VHE Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 11/30] KVM: arm64: Do not map the host fpsimd state to hyp in pKVM Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 12/30] KVM: arm64: Prevent kmemleak from accessing .hyp.data Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 13/30] KVM: arm64: Fix comment for __pkvm_vcpu_init_traps() Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 14/30] KVM: arm64: Change kvm_handle_mmio_return() return polarity Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 15/30] KVM: arm64: Move setting the page as dirty out of the critical section Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 16/30] KVM: arm64: Simplify vgic-v3 hypercalls Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 17/30] KVM: arm64: Add is_pkvm_initialized() helper Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 18/30] KVM: arm64: Introduce and use predicates that check for protected VMs Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 19/30] KVM: arm64: Move pstate reset value definitions to kvm_arm.h Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 20/30] KVM: arm64: Clarify rationale for ZCR_EL1 value restored on guest exit Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 21/30] KVM: arm64: Refactor calculating SVE state size to use helpers Fuad Tabba
2024-04-25 22:55 ` Oliver Upton
2024-04-26 2:05 ` Mark Brown
2024-04-26 7:20 ` Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 22/30] KVM: arm64: Move some kvm_psci functions to a shared header Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 23/30] KVM: arm64: Refactor reset_mpidr() to extract its computation Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 24/30] KVM: arm64: Refactor kvm_vcpu_enable_ptrauth() for hyp use Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 25/30] KVM: arm64: Reformat/beautify PTP hypercall documentation Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 26/30] KVM: arm64: Rename firmware pseudo-register documentation file Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 27/30] KVM: arm64: Document the KVM/arm64-specific calls in hypercalls.rst Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 28/30] KVM: arm64: Refactor setting the return value in kvm_vm_ioctl_enable_cap() Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 29/30] KVM: arm64: Restrict supported capabilities for protected VMs Fuad Tabba
2024-04-23 15:05 ` [PATCH v4 30/30] KVM: arm64: Force injection of a data abort on NISV MMIO exit Fuad Tabba
2024-04-30 8:12 ` [PATCH v4 00/30] KVM: arm64: Preamble for pKVM Oliver Upton
2024-04-30 15:36 ` Fuad Tabba
2024-05-01 15:43 ` Marc Zyngier
2024-05-01 16:01 ` (subset) " Marc Zyngier
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=86y18em44b.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=philmd@linaro.org \
--cc=qperret@google.com \
--cc=rananta@google.com \
--cc=seanjc@google.com \
--cc=smostafa@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).