Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 4 May 2020 16:09:40 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Mihai Carabas <mihai.carabas@oracle.com>
Cc:     linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, Jonathan Corbet <corbet@lwn.net>,
        linux-doc@vger.kernel.org
Subject: Re: [PATCH RFC 3/3] Documentation: x86: microcode: add description
 for metadata file
Message-ID: <20200504140940.GF15046@zn.tnic>
References: <1587972479-10971-1-git-send-email-mihai.carabas@oracle.com>
 <1587972479-10971-4-git-send-email-mihai.carabas@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1587972479-10971-4-git-send-email-mihai.carabas@oracle.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Apr 27, 2020 at 10:27:59AM +0300, Mihai Carabas wrote:
> +Here is an example of content for the metadata file::
> +   m + 0x00000122
> +   m - 0x00000120

That's not enough. Imagine a blob adds the MSR and a subsequent blob
adds *another* bit in that MSR. You need to be able express that.

IOW, I think it would be easier if each line describes exactly *one*
software-visible change brought by the microcode.

Also, what is the use case to say that you're adding a new MSR?

This would require to patch all the code that *potentially* might use
that MSR, to be able to handle a *change* in that MSR or it appearing
all of a sudden. Yuck.

I mean, an easy way to handle it is to say, "Hmm, nope, won't load that
ucode."

> +   c + 0x00000007 0x00 0x00000000 0x021cbfbb 0x00000000 0x00000000
> +   c - 0x00000007 0x00 0x00000000 0x021cbfbb 0x00000000 0x00000000

I don't think this'll work with the vendors as depending on the
configuration, CPUID on the different platforms could be different.

And then you might gonna have to specify CPUID for this particular
{family,model,stepping, ... } tuple which identifies the platform
uniquely so the c-line is insufficient.

IOW, I think it would be easier to be able to specify one CPUID bit per
line of being added/removed so that the post-load callback can handle
this properly. And this specification needs to be complete: i.e.

"I'm adding this CPUID bit for this family,model,stepping configurations
under this and that conditions".

And that needs to be describable by the "language" of the metadata.

So think of actual examples and then try to represent them with this
format.

But all of this is moot if you don't get a vendor buy-in into this. IOW,
microcode vendors need to agree to this format and adhere to the format
when allowing microcode to late-load.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette