linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Steve Capper <steve.capper@arm.com>,
	linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
	catalin.marinas@arm.com, ard.biesheuvel@linaro.org,
	jcm@redhat.com
Subject: Re: [PATCH V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support
Date: Fri, 7 Dec 2018 17:28:58 +0000	[thread overview]
Message-ID: <be06b735-c6b4-1520-73f6-02a3a8e8af45@arm.com> (raw)
In-Reply-To: <20181207152529.GB2682@edgewater-inn.cambridge.arm.com>



On 07/12/2018 15:26, Will Deacon wrote:
> On Fri, Dec 07, 2018 at 10:47:57AM +0000, Suzuki K Poulose wrote:
>> On 12/06/2018 10:50 PM, Steve Capper wrote:
>>> For cases where there is a mismatch in ARMv8.2-LVA support between CPUs
>>> we have to be careful in allowing secondary CPUs to boot if 52-bit
>>> virtual addresses have already been enabled on the boot CPU.
>>>
>>> This patch adds code to the secondary startup path. If the boot CPU has
>>> enabled 52-bit VAs then ID_AA64MMFR2_EL1 is checked to see if the
>>> secondary can also enable 52-bit support. If not, the secondary is
>>> prevented from booting and an error message is displayed indicating why.
>>>
>>> Technically this patch could be implemented using the cpufeature code
>>> when considering 52-bit userspace support. However, we employ low level
>>> checks here as the cpufeature code won't be able to run if we have
>>> mismatched 52-bit kernel va support.
>>>
>>> Signed-off-by: Steve Capper <steve.capper@arm.com>
>>>
>>
>> The patch looks good to me, except for one comment below.
>>
>>> ---
>>>
>>> Patch is new in V5 of the series
>>> ---
>>>    arch/arm64/kernel/head.S | 26 ++++++++++++++++++++++++++
>>>    arch/arm64/kernel/smp.c  |  5 +++++
>>>    2 files changed, 31 insertions(+)
>>>
>>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>>> index f60081be9a1b..58fcc1edd852 100644
>>> --- a/arch/arm64/kernel/head.S
>>> +++ b/arch/arm64/kernel/head.S
>>> @@ -707,6 +707,7 @@ secondary_startup:
>>>    	/*
>>>    	 * Common entry point for secondary CPUs.
>>>    	 */
>>> +	bl	__cpu_secondary_check52bitva
>>>    	bl	__cpu_setup			// initialise processor
>>>    	adrp	x1, swapper_pg_dir
>>>    	bl	__enable_mmu
>>> @@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
>>>    	ret
>>>    ENDPROC(__enable_mmu)
>>> +ENTRY(__cpu_secondary_check52bitva)
>>> +#ifdef CONFIG_ARM64_52BIT_VA
>>> +	ldr_l	x0, vabits_user
>>> +	cmp	x0, #52
>>> +	b.ne	2f > +
>>> +	mrs_s	x0, SYS_ID_AA64MMFR2_EL1
>>> +	and	x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
>>> +	cbnz	x0, 2f
>>> +
>>> +	adr_l	x0, va52mismatch
>>> +	mov	w1, #1
>>> +	strb	w1, [x0]
>>> +	dmb	sy
>>> +	dc	ivac, x0	// Invalidate potentially stale cache line
>>
>> You may have to clear this variable before a CPU is brought up to avoid
>> raising a false error message when another secondary CPU doesn't boot
>> for some other reason (say granule support) after a CPU failed with lack
>> of 52bitva. It is really a crazy corner case.
> 
> Can't we just follow the example set by the EL2 setup in the way that is
> uses __boot_cpu_mode? In that case, we only need one variable and you can
> detect a problem by comparing the two halves.

The only difference here is, the support is bolted at boot CPU time and hence
we need to verify each and every CPU, unlike the __boot_cpu_mode where we
check for mismatch after the SMP CPUs are brought up. If we decide to make
the choice later, something like that could work. The only caveat is the 52bit
kernel VA will have to do something like the above.

Cheers
Suzuki




> 
> Will
> 

  reply	other threads:[~2018-12-07 17:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 22:50 [PATCH V5 0/7] 52-bit userspace VAs Steve Capper
2018-12-06 22:50 ` [PATCH V5 1/7] mm: mmap: Allow for "high" userspace addresses Steve Capper
2018-12-07 19:56   ` Andrew Morton
2018-12-06 22:50 ` [PATCH V5 2/7] arm64: mm: Introduce DEFAULT_MAP_WINDOW Steve Capper
2018-12-06 22:50 ` [PATCH V5 3/7] arm64: mm: Define arch_get_mmap_end, arch_get_mmap_base Steve Capper
2018-12-06 22:50 ` [PATCH V5 4/7] arm64: mm: Offset TTBR1 to allow 52-bit PTRS_PER_PGD Steve Capper
2018-12-07 11:21   ` Catalin Marinas
2018-12-07 12:04   ` Suzuki K Poulose
2018-12-06 22:50 ` [PATCH V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support Steve Capper
2018-12-07 10:47   ` Suzuki K Poulose
2018-12-07 15:26     ` Will Deacon
2018-12-07 17:28       ` Suzuki K Poulose [this message]
2018-12-10 13:36         ` Will Deacon
2018-12-10 16:04           ` Steve Capper
2018-12-10 16:18             ` Will Deacon
2018-12-10 16:55               ` Steve Capper
2018-12-10 17:08                 ` Steve Capper
2018-12-10 17:42                   ` Steve Capper
2018-12-10 18:07                     ` Suzuki K Poulose
2018-12-06 22:50 ` [PATCH V5 6/7] arm64: mm: introduce 52-bit userspace support Steve Capper
2018-12-07 11:55   ` Catalin Marinas
2018-12-06 22:50 ` [PATCH V5 7/7] arm64: mm: Allow forcing all userspace addresses to 52-bit Steve Capper
2018-12-10 19:34 ` [PATCH V5 0/7] 52-bit userspace VAs Will Deacon
2018-12-11  9:13   ` Steve Capper

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=be06b735-c6b4-1520-73f6-02a3a8e8af45@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=jcm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=steve.capper@arm.com \
    --cc=will.deacon@arm.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