Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 17 Aug 2022 15:06:27 +0000
From:   Ashok Raj <ashok.raj@intel.com>
To:     Borislav Petkov <bp@alien8.de>
CC:     Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Tony Luck" <tony.luck@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        "LKML Mailing List" <linux-kernel@vger.kernel.org>,
        X86-kernel <x86@kernel.org>,
        "Andy Lutomirski" <luto@amacapital.net>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Jacon Jun Pan <jacob.jun.pan@intel.com>,
        Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH v3 3/5] x86/microcode: Avoid any chance of MCE's during
 microcode update
Message-ID: <Yv0D88jxFkXcc18o@araj-dh-work>
References: <20220817051127.3323755-1-ashok.raj@intel.com>
 <20220817051127.3323755-4-ashok.raj@intel.com>
 <Yvybq+hYT4tG/yAg@gmail.com>
 <Yvyfi9XC8bu0cOG+@gmail.com>
 <YvyiHGMbp2MtV0Vr@zn.tnic>
 <YvzXsf0mGEcOlZC5@araj-dh-work>
 <Yvzay5jOu5XBJpWa@zn.tnic>
 <YvzfebgOWVKYLClJ@araj-dh-work>
 <Yvz4/ASoX4SiXbhp@zn.tnic>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Yvz4/ASoX4SiXbhp@zn.tnic>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RyQK5a2OuB3/HRhKe/TIRfD7lLD5TFVaDadEYY4e8Yr3UA2UvuNG5yq6OcW6?=
 =?us-ascii?Q?oDARAVGMpCfsTf7WQXirzPq1PJp7HP6xz/Oey/kIoS4FpYADb5gD9/3GgjNW?=
 =?us-ascii?Q?Sq4XyPV4daCxYGDA+/n0iGVHJ+JhELPo6B1zir0gi2Wp4HNkJQantNVWNs/3?=
 =?us-ascii?Q?zOZN87Rl5RS0DJ1JtHH0nBkwBs0Rdbk0YyQbgVajR/5LrfktF8MNQYAAg/25?=
 =?us-ascii?Q?CSEY1yA+XhugOYEkq0csyC41PqBxr9nn9IjP0Z5wc/SRYxh3oqoeT6XKJT+v?=
 =?us-ascii?Q?T0VVuIXVZM8E9b7N1H99/ACduQX3WUG6KZwjPhLCHLaGka5N8H8GCqCqJTL0?=
 =?us-ascii?Q?im1b46O42hDmEkvfrKgy4ObNFUhqICQpJKPnZG1FOzR+qkCcwVAcsAH1iY6n?=
 =?us-ascii?Q?Y8s2pt6taIyG/LRwWsLUizwMpJhvdJOEWDnha18n3/A4dx0ajWvzEz3IqeWU?=
 =?us-ascii?Q?u/rpWEMLqzshXt8ciJUQ4RFUEjlZJJjk1BH0yFNFqlyoXlP7+ZNYwYDqCq/n?=
 =?us-ascii?Q?l4uZhL6Z8DwLCafmGiJLk38xuW4WBP5Q23SSqeyUFgHsQPdIVH8I0wM/xXJs?=
 =?us-ascii?Q?Nv4HGVpBCC7KKHLLwtvjY92zAlTI8LpJYcQEz0p4/isC/z/QFwmUkT2WR1dt?=
 =?us-ascii?Q?9ddRQMkv/4ILvwt5zzB8fp4fDBWyoP2P2cmTZ1rWTFT/DkQPGHDt2bRr6R4L?=
 =?us-ascii?Q?DSIb3KEWUNNJ7bQxuASAfmI9iJClVJrRdMH3zGzNg8vowU2xF+SZbmwqVtzm?=
 =?us-ascii?Q?eVJeXVF0eh56hoyo72U+lwCQhDPwzpgnwvxIWJqqyP/YrAISKGi6sRqxu+7H?=
 =?us-ascii?Q?cldGWEUamCanRa5VKVyXb4AWxEfo7SrmC0yj5HHLuUcRRwiqkCAUcAvgkOaN?=
 =?us-ascii?Q?IBwdl1CYe8/+Dv0y+lr+yoK/S7zNfMWoNnnKCHc+yquL7Q7D+mBfiAmtIjd/?=
 =?us-ascii?Q?AcZwBfFCnHGV58kNZ7+xOHAGo4J67KkwOegfus4hkmhZmZrNs+qGn93RnfyN?=
 =?us-ascii?Q?pKVcWuMh0dKDFkKvE/DFmb9W+6UNbyKXClL0L/ZHMDz/6yg/3854NYsghb8x?=
 =?us-ascii?Q?T9IQTY4pDMKgsj9Y1KLGULai0wGqbdTqzEZsc2DFZKUJJRjMLmw8/9nhB7dX?=
 =?us-ascii?Q?DxNH2GhMaNpmbtM/iqCMcXUK8DEJbqI9PnNrFG0JsinPnUbcCX3uznqyCIWz?=
 =?us-ascii?Q?aY8pRl6Q6Vb0oL1YeEB9Q9ngmHuqonyt59O017ySWlVTrraxq6gcVirFieKn?=
 =?us-ascii?Q?lcTZ31k0O2s8bCKISUnylXQTy5fcHjB5cE2YHSWOj4zlWmr7f+NL56R7m90c?=
 =?us-ascii?Q?8GUd30UCiDI56oecHa0/w2vrBrRXiDyVWdQ5R74b82Y98lQOnA9cL/NEUlna?=
 =?us-ascii?Q?Dq4u10gOsOr1GFpN5Z5SKldT0C29cNbYehSkcbxS2HCv6rQ8eOf3SlB6MGSo?=
 =?us-ascii?Q?yFYDrIjzk3IgUYtVmn7FA8kZWSkd5BE1uzZ1sMwY5PZsXdhTSX3Cxb5W9keE?=
 =?us-ascii?Q?zn2o4J4lF+wEw559SojDsK3lt8V6os2al+1qES764h8J25vNlGfYg+euORYo?=
 =?us-ascii?Q?spxGdhMG1Iy8r1rZ9ruXeJaEEheCrbqBnP65zWbUoVhkLQziFrnkNvP1B5re?=
 =?us-ascii?Q?KQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: ec3700b4-7cb2-4356-c774-08da806219f1
X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6201.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2022 15:06:45.8347
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8As3tnd9bS3+QZKkaB9CsA5MIEKb+Iu1UfhKaJhzPuWcnZuVION8WPs+BZ0571N7bgdiVjzeGgtIn97XshVLAw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2719
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Aug 17, 2022 at 04:19:40PM +0200, Borislav Petkov wrote:
> On Wed, Aug 17, 2022 at 12:30:49PM +0000, Ashok Raj wrote:
> > You will find out when system returns after reboot and hopefully wasn't
> > promoted to a cold-boot which will loose MCE banks.
> 
> Not good enough!

I probably misread your question.. are you suggesting we add some WARN when
we initiate late_load? I thought you were asking if the HW must signal
something and OS should log when an MCE happens if MCIP=1


> 
> This should issue a warning in dmesg that a potential MCE while update
> is running would cause a lockup. That is if we don't disable MCE around
> it.
> 
> If we decide to disable MCE, it should say shutdown.

Ok, that clarifies it.. "IF we choose to set MCIP=1, we should tell users
that hell can break loose, get under the table" :-)

> 
> > Meaning deal with the effect of a really rare MCE. Rather than trying to
> > avoid it. Taking the MCE is more important than finishing the update,
> > and loosing what the error signaled was trying to convey.
> 
> Right now I'm inclined to not do anything and warn of a potential rare
> situation.

Encouraging.. So I'll drop that patch from the list next time around.

> 
> > > > Shutdown, shutdown.. There is only 1 MCE no matter how many CPUs you have.
> > > 
> > > Because all CPUs are executing the loop? Or how do you decide this?
> > 
> > Fatal errors signaled with PCC=1 in the MCAx.STATUS is *ALWAYS*
> 
> What does that have to do with
> 
> "There is only 1 MCE no matter how many CPUs you have."
> 
> ?
> 
> That's bullsh*t. Especially if the machine can do LMCE.

Well, not outlandish :)

LMCE is only for recoverable errors. When we have a fatal error, sometimes
the signalling and consumption of poison are going in different directions.
In order to minimize exposure of bad data from being consumed,
*ALL* Intel processors have always broadcast fatal errors. This is the
history behind why we broadcast.

BTW: This is all legacy behavior. Nothing should come as surprise.

LMCE is best effort. This is the current state.

Cheers,
Ashok