public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: james.morse@arm•com (James Morse)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 04/13] arm64: alternatives: use tpidr_el2 on VHE hosts
Date: Tue, 17 Oct 2017 17:36:22 +0100	[thread overview]
Message-ID: <59E63186.4010005@arm.com> (raw)
In-Reply-To: <20171016095845.htg2g4jkyw3nvzub@armageddon.cambridge.arm.com>

Hi Catalin,

On 16/10/17 10:58, Catalin Marinas wrote:
> On Fri, Oct 13, 2017 at 05:50:45PM +0100, James Morse wrote:
>> On 13/10/17 16:31, Catalin Marinas wrote:
>>> On Fri, Sep 22, 2017 at 07:26:05PM +0100, James Morse wrote:
>>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>>> index cd52d365d1f0..8e4c7da2b126 100644
>>>> --- a/arch/arm64/kernel/cpufeature.c
>>>> +++ b/arch/arm64/kernel/cpufeature.c
>>
>>>> @@ -1308,3 +1309,25 @@ static int __init enable_mrs_emulation(void)
>>>>  }
>>>>  
>>>>  late_initcall(enable_mrs_emulation);
>>>> +
>>>> +int cpu_copy_el2regs(void *__unused)
>>>> +{
>>>> +	int do_copyregs = 0;
>>>> +
>>>> +	/*
>>>> +	 * Copy register values that aren't redirected by hardware.
>>>> +	 *
>>>> +	 * Before code patching, we only set tpidr_el1, all CPUs need to copy
>>>> +	 * this value to tpidr_el2 before we patch the code. Once we've done
>>>> +	 * that, freshly-onlined CPUs will set tpidr_el2, so we don't need to
>>>> +	 * do anything here.
>>>> +	 */
>>>> +	asm volatile(ALTERNATIVE("mov %0, #1", "mov %0, #0",
>>>> +				 ARM64_HAS_VIRT_HOST_EXTN)
>>>> +		    : "=r" (do_copyregs) : : );
>>>
>>> Can you just do:
>>>
>>> 	if (cpu_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
>>> 		write_sysreg(read_sysreg(tpidr_el1), tpidr_el2);
>>>
>>> At this point the capability bits should be set and the jump labels
>>> enabled.
>>
>> These are enabled too early, we haven't done patching yet.
>>
>> We need to copy tpidr_el1 -> tpidr_el2 on all CPUs that are online before code
>> patching.
>>
>> After code patching new CPUs set tpidr_el2 when they come online, so we don't
>> need to do the copy... but this enable method is still called. There is nothing
>> for us to do, and tpidr_el1 now contains junk, so the copy

> Ah, I get it now (should've read the comment but I usually expect the
> code to be obvious; it wasn't, at least to me, in this case ;)).

> You could have added the sysreg copying directly in the asm volatile.

I was trying to stick to the sysreg C accessors, and thought there would be more
registers that needed copying. (I discovered this VHE doesn't remap all the _ELx
registers quite late.)


> Anyway, I think it's better if we keep it entirely in C with this hunk
> (untested):

[...]

Yes, that looks much better. I got tangled up in 'which alternative', but you're
right, they are all applied in one go so it doesn't matter.


>	if (!READ_ONCE(alternatives_applied))
> 		write_sysreg(read_sysreg(tpidr_el1), tpidr_el2);

I don't think this READ_ONCE() is needed, that only matters within the
stop_machine()/alternatives-patching code that modifies the value on one CPU.


Thanks,

James

  reply	other threads:[~2017-10-17 16:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-22 18:26 [PATCH v3 00/13] arm64/firmware: Software Delegated Exception Interface James Morse
2017-09-22 18:26 ` [PATCH v3 01/13] KVM: arm64: Store vcpu on the stack during __guest_enter() James Morse
2017-09-22 18:26 ` [PATCH v3 02/13] KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation James Morse
2017-09-22 18:26 ` [PATCH v3 03/13] KVM: arm64: Change hyp_panic()s dependency on tpidr_el2 James Morse
2017-09-22 18:26 ` [PATCH v3 04/13] arm64: alternatives: use tpidr_el2 on VHE hosts James Morse
2017-10-13 15:31   ` Catalin Marinas
2017-10-13 16:50     ` James Morse
2017-10-16  9:58       ` Catalin Marinas
2017-10-17 16:36         ` James Morse [this message]
2017-10-16 10:17   ` Catalin Marinas
2017-09-22 18:26 ` [PATCH v3 05/13] KVM: arm64: Stop save/restoring host tpidr_el1 on VHE James Morse
2017-09-22 18:26 ` [PATCH v3 06/13] Docs: dt: add devicetree binding for describing arm64 SDEI firmware James Morse
2017-09-22 18:26 ` [PATCH v3 07/13] firmware: arm_sdei: Add driver for Software Delegated Exceptions James Morse
2017-10-13 15:49   ` Catalin Marinas
2017-09-22 18:26 ` [PATCH v3 08/13] arm64: Add vmap_stack header file James Morse
2017-10-13 15:42   ` Catalin Marinas
2017-10-17 16:34     ` James Morse
2017-09-22 18:26 ` [PATCH v3 09/13] arm64: kernel: Add arch-specific SDEI entry code and CPU masking James Morse
2017-10-16 13:41   ` Catalin Marinas
2017-10-17 16:34     ` James Morse
2017-10-18 10:54       ` Catalin Marinas
2017-09-22 18:26 ` [PATCH v3 10/13] firmware: arm_sdei: Add support for CPU and system power states James Morse
2017-10-16 13:52   ` Catalin Marinas
2017-10-17 16:34     ` James Morse
2017-09-22 18:26 ` [PATCH v3 11/13] firmware: arm_sdei: add support for CPU private events James Morse
2017-09-22 18:26 ` [PATCH v3 12/13] arm64: acpi: Remove __init from acpi_psci_use_hvc() for use by SDEI James Morse
2017-09-22 18:26 ` [PATCH v3 13/13] firmware: arm_sdei: Discover SDEI support via ACPI James Morse

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=59E63186.4010005@arm.com \
    --to=james.morse@arm$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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