From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] KVM: arm64: Reuse struct cpu_fp_state to track the guest FP state
Date: Sat, 02 Mar 2024 11:30:51 +0000 [thread overview]
Message-ID: <86y1b027mc.wl-maz@kernel.org> (raw)
In-Reply-To: <20240229-kvm-arm64-group-fp-data-v2-2-276de0d550e8@kernel.org>
On Thu, 29 Feb 2024 21:47:35 +0000,
Mark Brown <broonie@kernel.org> wrote:
>
> At present we store the various bits of floating point state individually
> in struct kvm_vcpu_arch and construct a struct cpu_fp_state to share with
> the host each time we exit the guest. Let's simplify this a little by
> having a struct cpu_fp_state in the struct kvm_vcpu_arch and initialising
> this while initialising the guest.
This structure is only useful to the physical CPU we run on, and does
not capture anything that is related to the guest state. Why should it
live in the vcpu structure, duplicating things we already have?
This is just making things even more opaque.
If you need to add such a structure so that you can know what to
save/restore on context switch, then attach it to the per-CPU data
structure we already have.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-02 11:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 21:47 [PATCH v2 0/2] KVM: arm64: Store a cpu_fp_state directly in the vCPU data Mark Brown
2024-02-29 21:47 ` [PATCH v2 1/2] KVM: arm64: Rename variable for tracking ownership of FP state Mark Brown
2024-02-29 21:47 ` [PATCH v2 2/2] KVM: arm64: Reuse struct cpu_fp_state to track the guest " Mark Brown
2024-03-02 11:30 ` Marc Zyngier [this message]
2024-03-04 16:27 ` 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=86y1b027mc.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/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 NNTP newsgroup(s).