From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: David Brazdil <dbrazdil@google.com>,
kvmarm@lists.cs.columbia.edu,
Catalin Marinas <catalin.marinas@arm.com>,
James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
Christoph Lameter <cl@linux.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@android.com,
Andrew Scull <ascull@google.com>
Subject: Re: [PATCH v4 05/10] kvm: arm64: Remove hyp_adr/ldr_this_cpu
Date: Tue, 29 Sep 2020 18:46:23 +0100 [thread overview]
Message-ID: <2221d6a88c4077b7e0a4ce2ac5f50a45@kernel.org> (raw)
In-Reply-To: <20200929173407.GC14317@willie-the-truck>
On 2020-09-29 18:34, Will Deacon wrote:
> On Tue, Sep 22, 2020 at 09:49:05PM +0100, David Brazdil wrote:
>> The hyp_adr/ldr_this_cpu helpers were introduced for use in hyp code
>> because they always needed to use TPIDR_EL2 for base, while
>> adr/ldr_this_cpu from kernel proper would select between TPIDR_EL2 and
>> _EL1 based on VHE/nVHE.
>>
>> Simplify this now that the hyp mode case can be handled using the
>> __KVM_VHE/NVHE_HYPERVISOR__ macros.
>>
>> Acked-by: Andrew Scull <ascull@google.com>
>> Acked-by: Will Deacon <will@kernel.org>
>> Signed-off-by: David Brazdil <dbrazdil@google.com>
>> ---
>> arch/arm64/include/asm/assembler.h | 29 +++++++++++++++++++----------
>> arch/arm64/include/asm/kvm_asm.h | 14 +-------------
>> arch/arm64/kvm/hyp/hyp-entry.S | 2 +-
>> 3 files changed, 21 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/assembler.h
>> b/arch/arm64/include/asm/assembler.h
>> index 54d181177656..86e0ef79a799 100644
>> --- a/arch/arm64/include/asm/assembler.h
>> +++ b/arch/arm64/include/asm/assembler.h
>> @@ -218,6 +218,23 @@ lr .req x30 // link register
>> str \src, [\tmp, :lo12:\sym]
>> .endm
>>
>> + /*
>> + * @dst: destination register (32 or 64 bit wide)
>
> nit: this comment is wrong as I don't think mrs can take a W register
> as the destination argument. I'm assuming Marc can fix that up.
Indeed. I'll fix it locally.
Another thing is that this patch is going to clash with the Ghostbuster
branch (the hyp-entry.S hunk goes), but we can deal with that.
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-09-29 17:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 20:49 [PATCH v4 00/10] Independent per-CPU data section for nVHE David Brazdil
2020-09-22 20:49 ` [PATCH v4 01/10] kvm: arm64: Partially link nVHE hyp code, simplify HYPCOPY David Brazdil
2020-09-22 20:49 ` [PATCH v4 02/10] kvm: arm64: Move nVHE hyp namespace macros to hyp_image.h David Brazdil
2020-09-22 20:49 ` [PATCH v4 03/10] kvm: arm64: Only define __kvm_ex_table for CONFIG_KVM David Brazdil
2020-09-22 20:49 ` [PATCH v4 04/10] kvm: arm64: Remove __hyp_this_cpu_read David Brazdil
2020-09-29 17:30 ` Will Deacon
2020-09-22 20:49 ` [PATCH v4 05/10] kvm: arm64: Remove hyp_adr/ldr_this_cpu David Brazdil
2020-09-29 17:34 ` Will Deacon
2020-09-29 17:46 ` Marc Zyngier [this message]
2020-09-22 20:49 ` [PATCH v4 06/10] kvm: arm64: Add helpers for accessing nVHE hyp per-cpu vars David Brazdil
2020-09-22 20:49 ` [PATCH v4 07/10] kvm: arm64: Duplicate arm64_ssbd_callback_required for nVHE hyp David Brazdil
2020-09-29 17:37 ` Will Deacon
2020-09-22 20:49 ` [PATCH v4 08/10] kvm: arm64: Create separate instances of kvm_host_data for VHE/nVHE David Brazdil
2020-09-22 20:49 ` [PATCH v4 09/10] kvm: arm64: Set up hyp percpu data for nVHE David Brazdil
2020-09-29 17:50 ` Will Deacon
2020-09-22 20:49 ` [PATCH v4 10/10] kvm: arm64: Remove unnecessary hyp mappings David Brazdil
2020-09-29 17:49 ` Will Deacon
2020-09-24 10:10 ` [PATCH v4 00/10] Independent per-CPU data section for nVHE Christopher Lameter
2020-10-02 8:19 ` 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=2221d6a88c4077b7e0a4ce2ac5f50a45@kernel.org \
--to=maz@kernel.org \
--cc=ascull@google.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=dbrazdil@google.com \
--cc=dennis@kernel.org \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@gmail.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tj@kernel.org \
--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