[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rspkz663fg7i7jomvg5ehv3ldr6ayehttb7vgwwzsfsxafzb5y@uhqcadvsmw6f>
Date: Fri, 21 Mar 2025 10:01:17 +0100
From: Stefano Garzarella <sgarzare@...hat.com>
To: Jarkko Sakkinen <jarkko@...nel.org>, Borislav Petkov <bp@...en8.de>,
Tom Lendacky <thomas.lendacky@....com>
Cc: Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
x86@...nel.org, linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
Dov Murik <dovmurik@...ux.ibm.com>, Dionna Glaze <dionnaglaze@...gle.com>,
linux-coco@...ts.linux.dev, James Bottomley <James.Bottomley@...senpartnership.com>,
Claudio Carvalho <cclaudio@...ux.ibm.com>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH v3 1/4] x86/sev: add SVSM vTPM probe/send_command
functions
On Thu, Mar 20, 2025 at 07:30:43PM +0200, Jarkko Sakkinen wrote:
>On Thu, Mar 20, 2025 at 06:16:19PM +0100, Borislav Petkov wrote:
>> On Thu, Mar 20, 2025 at 05:03:09PM +0200, Jarkko Sakkinen wrote:
>> > > I can do that, I slightly prefer BIT_ULL() macro, but I don't have a strong
>> > > opinion on my side.
>> > > @Borislav since you suggested it, WDYT?
>> >
>> > Either goes for me. Sorry for nitpicking that :-) The first comment
>> > stil applies.
>>
>> Bit 8 is a lot better than 0x100.
>>
>> Let's give a better example:
>>
>> 0x0000000008000000
>>
>> or
>>
>> BIT_ULL(27)
>>
>> :-)
>
>Sure, I'm fine with using BIT_ULL() :-)
Yeah, we all agree :-)
>
>>
>> While I'm here: I'm guessing I'll route patches 1 and 4 through tip once
>> they're ready to go and give Jarkko an immutable branch he can base the other
>> two ontop.
>>
>> Agreed?
>
>Works for me.
Just a note, patch 2 adds `include/linux/svsm_vtpm.h`, that file is
basically a translation of the AMD SVSM specification into structures
and functions used to communicate with SVSM in the way it is defined by
the specification.
I realized that the file does not fall under any section of MAINTAINERS.
How do you suggest we proceed?
Should we create an SVSM section to maintain it, including the TPM
driver and future other drivers,etc.?
Or include it in other sections? Which one in this case?
I'm willing to help both as a sub-maintainer and reviewer of course, but
I would like your advice.
Thanks,
Stefano
Powered by blists - more mailing lists