Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp685246imd; Fri, 26 Oct 2018 15:25:48 -0700 (PDT) X-Google-Smtp-Source: AJdET5cbq163aPv10/ES/eIUTjBIzRjxTMLHrcZDWTDxHksoXOCRCDCj+vhgDDGR729eGolCIA3N X-Received: by 2002:a63:5c61:: with SMTP id n33-v6mr4989420pgm.1.1540592748545; Fri, 26 Oct 2018 15:25:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540592748; cv=none; d=google.com; s=arc-20160816; b=Ov+HLxMaRc59H985vGbO0VIJ8adro/TQ5Q/LB8d7ckQrSr5tKD6PWX25YZcdrXAhE9 3kTDcMY0vCxlNSA7jJyWrQwS04l8eKPzVSjTYUADHVbNzihBz1ROWALNr+2Xq6SmifI8 4CqBZYmJiGAzJjI1G8AAgQtpBDnMRf760d9k1khB2OrP/O9GaycIRmi5NCoBq/VKo0eQ 6ITHc4cU8ftYP8fv1I+OFqq5Y5PEcaNSLlr6GG6gljLXP+OmG6YEyhMW+pxe+n+kHwTZ t42XrDez+MTbfLJS2DUpwrplnt3T30CUPmASmhsMbm84B36UpZe7WDn8Zsgy1rHyBqW1 e8Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=VgXYvvW3IvJ2U341Bx1ucsWo3t2nQ7ozJ6irNehw9m0=; b=v3AnBj3OiTh1wQ9OdwVELQ+z2CJJqoZjAROV+TJfjGEzOIKUcq8exr5OIsr4dLfB+y l5Jzjv5eW6EflzXLSjyMf5SpVda/RGYUhwblnjtndR65n8gVVWY0K4FAJtdYmvZ5LAM9 4p886jm143Ejs8SKSzZGJeEoLxdkDVVJcyMIFdhHGyOzpaZjSeAHD5qTjX1Bv8xvQsQW 3+brgr8MxrkzZZupmG+Zq2pLY2CJCsx8mfulcyKO70AjX0vcA1kwzXwBQ5UFE4ULcPGq DuzAQYUn3h5GUwtQMnbOs4ldRk6PRocpYjWQfasjJgsBXEKZ7zOtf1c4PYXStAOhFf+g hUgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y8-v6si9207755pgl.297.2018.10.26.15.25.33; Fri, 26 Oct 2018 15:25:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728166AbeJ0HDw (ORCPT + 99 others); Sat, 27 Oct 2018 03:03:52 -0400 Received: from mail.skyhub.de ([5.9.137.197]:42788 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728132AbeJ0HDw (ORCPT ); Sat, 27 Oct 2018 03:03:52 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Geu0eJYTX6VR; Sat, 27 Oct 2018 00:25:03 +0200 (CEST) Received: from nazgul.tnic (unknown [185.30.24.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id BF2DF1EC05B0; Sat, 27 Oct 2018 00:25:03 +0200 (CEST) Date: Sat, 27 Oct 2018 00:25:17 +0200 From: Borislav Petkov To: Petr Tesarik Cc: lijiang , linux-kernel@vger.kernel.org, bhe@redhat.com, x86@kernel.org, kexec@lists.infradead.org, mingo@redhat.com, tglx@linutronix.de, dyoung@redhat.com Subject: Re: [PATCH] kdump, vmcoreinfo: Export sme_me_mask value to vmcoreinfo Message-ID: <20181026222517.GB26927@nazgul.tnic> References: <20181026093630.8520-1-lijiang@redhat.com> <053CC83A-9A95-4C12-9627-AABD1427DA9C@alien8.de> <1263471c-a27d-a698-15f0-b5947f13ea93@redhat.com> <20181026182440.20a4b107@ezekiel.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20181026182440.20a4b107@ezekiel.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 26, 2018 at 06:24:40PM +0200, Petr Tesarik wrote: > But we need the MSR value from the panic kernel environment, not while > the production kernel is still running, right? Actually, we need only the encryption bit number (and it should be 0 otherwise to denote SME wasn't enabled). I guess something like VMCOREINFO_NUMBER(sme_mask); which gets written by the kexec-ed kernel. > If so, then this reminds me that I have wanted for a long time to store > more of the hardware state in a vmcore NOTE after a kernel crash ... > control registers, MSRs and whatnot. Of course, this would be a > long-term project, but I wonder what other people think about it in > general. I guess that sounds like a good idea - the more relevant hw info for debugging, the better. Determining the important MSRs to save would need a bit of a pondering over though. For example, some MSRs are per-core, some per-socket, etc... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --