From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1432155AbdDYQs5 (ORCPT ); Tue, 25 Apr 2017 12:48:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52320 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1176733AbdDYQsu (ORCPT ); Tue, 25 Apr 2017 12:48:50 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1999723E6D0 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dvlasenk@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1999723E6D0 Subject: Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them To: Borislav Petkov References: <20170425152705.13991-1-dvlasenk@redhat.com> <20170425160659.o5h5hb27ovwlwlei@pd.tnic> <20170425162317.pfy6amlgnj2a6xgd@pd.tnic> Cc: Ingo Molnar , Andy Lutomirski , Brian Gerst , Peter Zijlstra , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org From: Denys Vlasenko Message-ID: Date: Tue, 25 Apr 2017 18:48:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170425162317.pfy6amlgnj2a6xgd@pd.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 25 Apr 2017 16:48:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/25/2017 06:23 PM, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: >> On 04/25/2017 06:06 PM, Borislav Petkov wrote: >>> Pls no. Not every MSR for every family. Only the 4 which are actually >>> being used. We can't hold in here the full 32-bit MSR space. >> >> The replacement of four define names is not the purpose >> of the proposed patch. >> >> The patch was prompted by the realization that these particular MSRs >> are so badly and inconsistently documented that it takes many hours >> of work and requires reading of literally a dozen PDFs to figure out >> what are their names, which CPUs have them, and what bits are known. > > They're all documented in the respective BKDGs or revision guides. Yes. For some definition of "documented". Let's say you are looking at all available documentation for Fam10h CPUs - BKDG, Revision Guide, five volumes of APM, software optimization guide. Eight documents. If you read all of them, you can find exactly one mention that MSR 0xC0011029 exists. It is mentioned by number. As a reader of this documentation, can you find out what is it? Does it have a name, at least? You are right that kernel is not exactly the best place to store more info about such things, but AMD probably won't accept my edits to their documentation.