From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id BBE3236A033
	for <linux-kernel@vger.kernel.org>; Fri, 13 Mar 2026 07:54:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1773388452; cv=none; b=bfQMqpxnOu1HCqWdlZ44mY/tLqEFGMNjzgzqr+SAJHLoD5KEcU320yheMFLtWe3f4odnTmYHKVwrZoDoVIAAq5j0EIUeG/QAhlz8P1Oe5UUyZX319O3uF2G7zfZuVhzvnOkNLDxmf0xBNQvVOiYS8UC3S6GncCx42p5vH130viQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1773388452; c=relaxed/simple;
	bh=LKcUOPy/VD9riQNc5+FF8I1L4Y8Sz4agfA9RcvJdzzc=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=bINiBi483JFaBoBKxkK4gk/SZ57BvKH4GrQnS9omIoEgikmcWFVspFn/CAhQ0qxGOh764IAD1INY/xjhwGRLJUeSZ2n0hmJiowWIuer380vPnJJeFB1Lr8EXN5n27fSE1Y4HDJ6+2GnkZt7iGiJb9ghN+btIe2UPHNeFX32cxxo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
	by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A27B71596;
	Fri, 13 Mar 2026 00:54:03 -0700 (PDT)
Received: from [10.164.18.48] (unknown [10.164.18.48])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9C2793F73B;
	Fri, 13 Mar 2026 00:54:07 -0700 (PDT)
Message-ID: <edcb9acf-359f-45db-9574-10337c0928fd@arm.com>
Date: Fri, 13 Mar 2026 13:24:04 +0530
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: Clear VTCR_EL2 in __init_el2_stage2()
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Oliver Upton <oupton@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 linux-kernel@vger.kernel.org
References: <20260313053857.1277828-1-anshuman.khandual@arm.com>
 <87sea4chrw.wl-maz@kernel.org>
Content-Language: en-US
From: Anshuman Khandual <anshuman.khandual@arm.com>
In-Reply-To: <87sea4chrw.wl-maz@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13/03/26 12:55 PM, Marc Zyngier wrote:
> On Fri, 13 Mar 2026 05:38:57 +0000,
> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>
>> Clear VTCR_EL2 along with VTTBR_EL2 register in __init_el2_stage2(), which
>> ensures that MMU stage-2 translation remain disabled. Although clearing out
>> VTTBR_EL2 probably should have been sufficient but adding VTCR_EL2 improves
>> overall safety.
> 
> This serves no purpose whatsoever. Even the write to VTTBR_EL2 is
> pointless, and writing 0 is no better than writing *any* other value.
> > The only thing that matters at this stage is HCR_EL2.VM, which
> actually controls stage-2 translation (contrary to your above
> assertion). This of course is not captured by this macro.
> 
> So what are you *really* trying to achieve?

To keep VTTBR_EL2 and VTCR_EL2 cleared (and prepared) if and when
HCR_EL2_VM gets enabled. But it can be argued that these registers
need not have to be cleared now and can just be initialised before
setting up HCR_EL2_VM itself. In which case should we drop
__init_el2_stage2() entirely ?