From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
James Clark <james.clark@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Dongli Zhang <dongli.zhang@oracle.com>
Subject: Re: [PATCH v2 5/5] KVM: arm64: Exclude FP ownership from kvm_vcpu_arch
Date: Mon, 25 Mar 2024 09:23:18 +0000 [thread overview]
Message-ID: <87cyrism0p.wl-maz@kernel.org> (raw)
In-Reply-To: <252bc993-e93d-4412-bfc6-13930b80dbd8@sirena.org.uk>
On Mon, 25 Mar 2024 00:27:43 +0000,
Mark Brown <broonie@kernel.org> wrote:
>
> > > - Add support for the V registers in the sysreg interface when SVE is
> > > enabled.
>
> > We already support the V registers with KVM_REG_ARM_CORE_REG(). Why
> > would you add any new interface for this? The kernel should be
> > perfectly capable of dealing with the placement of the data in the
> > internal structures, and there is no need to tie the userspace ABI to
> > how we deal with that placement (kvm_regs is already purely
> > userspace).
>
> This was referring to the fact that currently when SVE is enabled access
> to the V registers as V registers via _CORE_REG() is blocked and they
> can only be accessed as a subset of the Z registers (see the check at
> the end of core_reg_size_from_offset() in guest.c).
But what behaviour do you expect from allowing such a write? Insert in
place? Or zero the upper bits of the vector, as per R_WKYLB? One is
wrong, and the other wrecks havoc on unsuspecting userspace.
My take on this is that when a VM is S*E aware, only the writes to the
largest *enabled* registers should take place. This is similar to what
we do for FP/SIMD: we only allow writes to the V registers, and not to
Q, D, S, H or B, although that happens by construction. For S*E,
dropping the write on the floor (or return some error that userspace
will understand as benign) is the least bad option.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-03-25 9:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 17:09 [PATCH v2 0/5] KVM: arm64: Move host-specific data out of kvm_vcpu_arch Marc Zyngier
2024-03-22 17:09 ` [PATCH v2 1/5] KVM: arm64: Add accessor for per-CPU state Marc Zyngier
2024-03-25 14:31 ` Suzuki K Poulose
2024-03-22 17:09 ` [PATCH v2 2/5] KVM: arm64: Exclude host_debug_data from vcpu_arch Marc Zyngier
2024-03-26 10:24 ` Suzuki K Poulose
2024-03-22 17:09 ` [PATCH v2 3/5] KVM: arm64: Exclude mdcr_el2_host from kvm_vcpu_arch Marc Zyngier
2024-03-26 10:25 ` Suzuki K Poulose
2024-03-22 17:09 ` [PATCH v2 4/5] KVM: arm64: Exclude host_fpsimd_state pointer " Marc Zyngier
2024-03-22 17:09 ` [PATCH v2 5/5] KVM: arm64: Exclude FP ownership " Marc Zyngier
2024-03-22 17:52 ` Mark Brown
2024-03-23 19:06 ` Marc Zyngier
2024-03-25 0:27 ` Mark Brown
2024-03-25 9:23 ` Marc Zyngier [this message]
2024-03-25 14:57 ` Mark Brown
2024-03-27 9:04 ` Marc Zyngier
2024-03-25 0:28 ` Mark Brown
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=87cyrism0p.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=dongli.zhang@oracle.com \
--cc=james.clark@arm.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--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