Re: [RFC 0/8] use __create_pgd_mapping() to implement idmap and unify codes

From: Pingfan Liu <kernelfans@gmail.com>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	 Kristina Martsenko <kristina.martsenko@arm.com>,
	James Morse <james.morse@arm.com>,
	Steven Price <steven.price@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	 Anshuman Khandual <anshuman.khandual@arm.com>,
	Atish Patra <atish.patra@wdc.com>,
	 Mike Rapoport <rppt@kernel.org>,
	Logan Gunthorpe <logang@deltatee.com>,
	Mark Brown <broonie@kernel.org>,
	 "Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [RFC 0/8] use __create_pgd_mapping() to implement idmap and unify codes
Date: Thu, 15 Apr 2021 10:14:09 +0800	[thread overview]
Message-ID: <CAFgQCTvq3VAm7yztoR9jw=EYUdS1K-cuTKcUn_DNdGsnxMyrHA@mail.gmail.com> (raw)
In-Reply-To: <CA+CK2bCLwRWiNf-pUbD_qSRPt=taQxSvrEMOP-8D7FgNhXQKug@mail.gmail.com>

Hi Pavel,

First of all, sorry to stir up this topic too late.

On Wed, Apr 14, 2021 at 10:06 PM Pavel Tatashin
<pasha.tatashin@soleen.com> wrote:
>
[...]
> Hi Pingfan,
>
> The MMU enabled kexec code has been in development for a while, and
> has gone through several iterations:
>

Yes, I have gone through the whole iterations after reviewing v12.

> 1. simply reserve memory (similar to crash kernel) so no relocation is
> needed. The approach was only ~50 LOC, but since this was an ARM64
> specific problem I was asked to fix it in ARM64, not in generic code.
> 2. The second approach was to use idmap (as you are proposing now),
> but James Morse explained to me that there are arm systems that have
> very high starting physical addresses that they cannot cover all
> physical memory via idamp. So, I cannot assume that I can idmap any
> page in PA.

I think here, the exact blocking factor is the routines in hand can
not set up idmap. But the current routines have the capability if
enhanced. And  it turns out easy to achieve the goal by redefining
CONFIG_PGTABLE_LEVEL.

> 3. The third approach was to unify some of page table management code
> with hibernations (trans_pgd), and use contiguous VA maps, so the
> relocation function can be as simply as possible. However, both, Eric
> Biederman and James Morse asked me to change it to a linear map
> instead: to be inline with other arches, and also for easier
> debugging.
> 4. The fourth approach is the current one, I am using a linear map,
> and a lot of patches for this project have already landed into the
> mainline. The last set of changes does not add any new LOC: "18 files
> changed, 315 insertions(+), 330 deletions(-)", as all the preliminary
> work has landed upstream.
>
> What is the benefit of going back to approach 2, when the current
> approach has already been agreed with James and Eric, and does not add
> new complexity, as the net LOC change is negative?
>

It takes me some time to understand the stub handling. But James is
expert on this field and sure about it.  In contrast, idmap is similar
to linear map, meanwhile free of kvm stub handling. As a result, the
code scarcely needs change against MMU-disabled code.

Anyway, the primary target of my series is to share the common code
with [5/8] and [8/8].

Thanks,
Pingfan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel