[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c1246c8-6965-b8b6-eab1-df0761a2853a@amd.com>
Date: Mon, 10 Mar 2025 08:56:53 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Stefano Garzarella <sgarzare@...hat.com>,
Jarkko Sakkinen <jarkko@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
Claudio Carvalho <cclaudio@...ux.ibm.com>, Peter Huewe <peterhuewe@....de>,
x86@...nel.org, Dov Murik <dovmurik@...ux.ibm.com>,
linux-coco@...ts.linux.dev, Dionna Glaze <dionnaglaze@...gle.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
Jason Gunthorpe <jgg@...pe.ca>, linux-integrity@...r.kernel.org,
linux-kernel@...r.kernel.org, Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC PATCH v2 2/6] x86/sev: add SVSM vTPM probe/send_command
functions
On 3/10/25 08:51, Borislav Petkov wrote:
> On Mon, Mar 10, 2025 at 08:27:37AM -0500, Tom Lendacky wrote:
>> I don't think anything needs to be checked or printed.
>
> Yes.
>
>> If you want to do anything, just issue a pr_info() with the features value
>> (and maybe the platform_cmds value, too). Issuing a pr_warn() here would be
>> like issuing a pr_warn() for a new CPUID value that the current kernel
>> doesn't know about.
>
> I still don't get the need to print anything. Why?
It isn't needed. It's similar to "device" information/capabilities.
Maybe pr_debug() then? But I'm also fine with not printing anything.
Thanks,
Tom
>
Powered by blists - more mailing lists