linux-kernel - Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO

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: <26518d17-cc9e-ac0d-aac0-b65dbe22af68@linux.intel.com>
Date:   Tue, 18 May 2021 14:05:20 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Raj Ashok <ashok.raj@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO

> I'm not actually trying to propose things.  I'm really just trying to
> get an idea why the implementation ended up how it did.  I actually
> entirely respect the position that the KVM code is a monster and
> shouldn't get reused.  That seems totally reasonable.

Mainly because it's relatively simple and straight forward to do it this 
way, Yes I know, that's a shocking concept, but sometimes it works even 
in Linux code.

>
> What isn't reasonable is the lack of documentation of these design
> decisions in the changelogs.  My goal here is to raise the quality of
> the changelogs so that other reviewers and maintainers don't have to ask
> these questions when they perform their reviews.
>
> This is honestly the best way I know to help get this code merged as
> soon as possible.  If I'm not helping, please let me know.  I'm happy to
> spend my time elsewhere.

I'm sure the commit logs can be improved and I appreciate your feedback.

I don't think every commit log needs to be an extended essay meandering 
all over the possible design space, talking about everything that could 
have been and wasn't. The way code is normally written is that we don't 
do an exhaustive search of possible options, but instead we pick a 
reasonable path and as long as that works and doesn't have too many 
problems we just stick to it. The commit log reflects that single path 
chosen, with only rare exceptions to talk about dead alleys.

In this case you can even see that multiple independent efforts (AMD and 
Intel) came mostly to fairly similar implementations, so the path chosen 
wasn't really that strange or non obvious.

Also overall I would appreciate if people would focus more on the code 
than the commit logs. Commit logs are important, but in the end what 
really matters is that the code is correct.

-Andi