linux-kernel - Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <af9e7292f723f808406510f437d5b0eb@kernel.org>
Date:   Fri, 24 Jan 2020 13:34:35 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Quentin Perret <qperret@...gle.com>
Cc:     Will Deacon <will@...nel.org>, Mike Rapoport <rppt@...nel.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-arm-kernel@...ts.infradead.org,
        Mike Rapoport <rppt@...ux.ibm.com>,
        kvmarm@...ts.cs.columbia.edu, kernel-team@...roid.com
Subject: Re: [PATCH v2 0/1] arm/arm64: add support for folded p4d page tables

Hi Quentin,

On 2020-01-24 12:20, Quentin Perret wrote:
> Hi Marc,
> 
> On Wednesday 22 Jan 2020 at 18:56:38 (+0000), Marc Zyngier wrote:
>> But maybe this is the reason we've all been waiting for, for which we
>> sacrifice 32bit KVM host on the altar of progress, and finally move 
>> along.
>> 
>> Will and I are the only known users, and that'd be a good incentive to
>> experience some if this 64bit goodness... ;-)

[future work for which 32bit support gets in the way]

> This would a be perfectly reasonable and acceptable overhead if this 
> had
> to be done to keep 32bit KVM host support for a real user community, 
> but
> since it doesn't seem to exist (?), fighting with the above options
> feels like a lot of wasted efforts. (Note: I am not implying that Will
> and you are not real persons, but well, you see what I mean ;-)).

I don't disagree at all. To be honest, I've been on the cusp of getting
rid of it for a while, for multiple reasons:

- It has no users (as you noticed)
- It is hardly tested (a consequence of the above)
- It isn't feature complete (no debug, no PMU)
- It doesn't follow any of the evolution of the architecture (a more
   generic feature of the 32bit port, probably because people run their
   64bit-capable cores in 64bit mode)
- It is becoming a mess of empty stubs

The maintenance aspect hasn't been a real problem so far. Even the NV
support is only about 200 lines of stubs. But what you have in mind is
going to be much more invasive, and I wouldn't want an unused feature to
get in the way.

What I may end-up doing is to send a RFC series to remove the 32bit host
support from the tree during in the 5.6 cycle, targeting 5.7. If someone
shouts loudly during that time frame, we keep it and you'll have to work
around it. If nobody cares, then dropping it is the right thing to do.

Would that be OK with you?

         M.
-- 
Jazz is not dead. It just smells funny...