From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7F09C4167B for ; Tue, 5 Dec 2023 16:55:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235489AbjLEQy5 (ORCPT ); Tue, 5 Dec 2023 11:54:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235061AbjLEQyj (ORCPT ); Tue, 5 Dec 2023 11:54:39 -0500 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60E631713 for ; Tue, 5 Dec 2023 08:53:50 -0800 (PST) Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1d03cf821e3so26704175ad.3 for ; Tue, 05 Dec 2023 08:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701795230; x=1702400030; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=XMQYF2quagt/GPGUodoc4MiIW5ZQeF7Y4GziD01rWxY=; b=jKUL6Pb2ELt3dBIcP8SfhUzC2eRufsrPX+BPDTaA6tkwYPYCQJEAQHDG11BWQS9xME KBaPHlUeak7SGC/WHLeCJ2WRLzgTDsKROnHd2r2O7UxR66/i2tAwB2CiwYo72gOuG0l0 8kSdblTIhXmsAjNdAXCejlwHNbozSfjUu6VO28TFyl1Oue3+fPMss2cNDsmHBUvSTATO YK3T0G+qzrPlnrPIHfnkQtZC4GNHGy0Dzvq536Q9nPqUJC85/R/k0y0fpaib/tS3YlZr MHIfI4y/FAFPWOA5CX/enymHMqpEdzur0J8JMl3nZipCYDwgt/Vu8MQaWZu2yuoWI5mZ QmuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701795230; x=1702400030; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XMQYF2quagt/GPGUodoc4MiIW5ZQeF7Y4GziD01rWxY=; b=iF28PZ9pRBvmgTRgDSHSHvs9C+M0FjqZgUyxzQe3JmIUmMhhG1B0tzM91uGUBjdnaK 1mv0/6rEQDufTp0kUQeM+K9b/sEC8Qn1hI7aSvQwBZYX2wkm49iDGnUlUh9QPijmTAC8 zvloATqFsXif1TW4gOYFZfPWHUkx6xbUypYUnP9dUpTzV8wO78J2cI9541ygFWTR7QK3 Lc2hbTrqbqFoNMRWU8PG7O3MUhXl1OOzGDLzsej/gIsSEMnUtehTTRVTyq7h6ahnbMw3 wO1OnGkdlXT3jlUbPy6ggCr4V3+DFy5q7Oeg2NvVQfqd33KS1eIK+O8LeRUJ346HMaOs PmWg== X-Gm-Message-State: AOJu0YyhGMAR4/4cjzXkQZLYfUeg8fv7thCHZYoduJ7ndRmxJPFKuboE ItCsiZrnHhAhIMYfbxeALeIFd7lM/fY= X-Google-Smtp-Source: AGHT+IEkDPF5kg0eFiaPieQqBbhN1nYVZJAxhuI3lfBP6e8BzlpfCIUB7mriD7s7nOD1m+hVQsJUWt4xndE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:8504:b0:1d0:96b7:7f4 with SMTP id bj4-20020a170902850400b001d096b707f4mr104464plb.12.1701795229655; Tue, 05 Dec 2023 08:53:49 -0800 (PST) Date: Tue, 5 Dec 2023 08:53:48 -0800 In-Reply-To: Mime-Version: 1.0 References: <9e80873fac878aa5d697cbcd4d456d01e1009d1f.1699527082.git.kai.huang@intel.com> <9b221937-42df-4381-b79f-05fb41155f7a@intel.com> <1a5b18b2-3072-46d9-9d44-38589cb54e40@intel.com> Message-ID: Subject: Re: [PATCH v15 22/23] x86/mce: Improve error log of kernel space TDX #MC due to erratum From: Sean Christopherson To: Dave Hansen Cc: Kai Huang , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "rafael@kernel.org" , Chao Gao , Tony Luck , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "kirill.shutemov@linux.intel.com" , "mingo@redhat.com" , "pbonzini@redhat.com" , "tglx@linutronix.de" , Isaku Yamahata , "nik.borisov@suse.com" , "hpa@zytor.com" , "sagis@google.com" , "imammedo@redhat.com" , "peterz@infradead.org" , "bp@alien8.de" , Len Brown , "sathyanarayanan.kuppuswamy@linux.intel.com" , Ying Huang , Dan J Williams , "x86@kernel.org" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 05, 2023, Dave Hansen wrote: > On 12/4/23 18:04, Sean Christopherson wrote: > > Joking aside, why shove TDX module ownership into KVM? It honestly sounds like > > a terrible fit, even without the whole TDX-IO mess. KVM state is largely ephemeral, > > in the sense that loading and unloading kvm.ko doesn't allocate/free much memory > > or do all that much initialization or teardown. > > Yeah, you have a good point there. We really do need some core code to > manage VMXON/OFF now that there is increased interest outside of > _purely_ running VMs. > > For the purposes of _this_ patch, I think I'm happy to leave open the > possibility that SEAMCALL can simply fail due to VMXOFF. For now, it > means that we can't attribute #MC's to the PAMT unless a VM is running > but that seems like a reasonable compromise for the moment. +1 > Once TDX gains the ability to "pin" VMXON, the added precision here will > be appreciated.