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 BD89A36C0DC
	for <linux-kernel@vger.kernel.org>; Fri, 13 Mar 2026 08:39:52 +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=1773391194; cv=none; b=jdJonks1jtxCg+ihYorgCcjFm6Ba7s7aYO6KWpoQ+FkF+iYeAX2jmHcGz9Cv0cDRhadMIiTzk3IbjJCmw4JWpF0u7PBSerHiRR0t61bdefMHfexE753r3ahGPN3mBI9zssTssB9F0GF1yw9v64O/0NU9/5w5xl3DV1C7J4M3w1E=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1773391194; c=relaxed/simple;
	bh=SRzx8LdqT5umWrKpgn06qDvT7Zd6JyzLh8Y0/MqqMig=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=So9iwkb8q2KvnwW8/VHfD7v5DdP65jmWCb40Gq2JO2mYPBc/dkP4jM6nRqAgmsHN0MomkRxjiK+HliyQNMWTsrTPmJutqklWzQm7moVyRavPyEYlxqa61eLur9NhJUdLkqA+Ie7kBRIoOe772nwnJkErnJO7hgGZcZJkOiajNoU=
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 D24F1165C;
	Fri, 13 Mar 2026 01:39:45 -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 D363D3F7BD;
	Fri, 13 Mar 2026 01:39:49 -0700 (PDT)
Message-ID: <949f02cf-9f26-40ba-9c68-1742e335e2b9@arm.com>
Date: Fri, 13 Mar 2026 14:09:46 +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> <edcb9acf-359f-45db-9574-10337c0928fd@arm.com>
 <87o6kscfon.wl-maz@kernel.org>
Content-Language: en-US
From: Anshuman Khandual <anshuman.khandual@arm.com>
In-Reply-To: <87o6kscfon.wl-maz@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit



On 13/03/26 1:41 PM, Marc Zyngier wrote:
> On Fri, 13 Mar 2026 07:54:04 +0000,
> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>
>> 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 ?
> 
> And something worth thinking of: the role of VTTBR_EL2.VMID when
> HCR_EL2.VM is 0.

Are you suggesting that VTTBR_EL2_VMID needs to be 0 even when
HCR_EL2_VM = 0 because of its corresponding TLB entries ? But
during system boot such possibilities might not really exist ?