[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48625a39-9e31-d7f2-dccf-74e9c27126f5@intel.com>
Date: Mon, 13 Dec 2021 07:08:07 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Brijesh Singh <brijesh.singh@....com>, x86@...nel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
linux-coco@...ts.linux.dev, linux-mm@...ck.org
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
Tom Lendacky <thomas.lendacky@....com>,
"H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Jim Mattson <jmattson@...gle.com>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>,
Dov Murik <dovmurik@...ux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@....com>,
Borislav Petkov <bp@...en8.de>,
Michael Roth <michael.roth@....com>,
Vlastimil Babka <vbabka@...e.cz>,
"Kirill A . Shutemov" <kirill@...temov.name>,
Andi Kleen <ak@...ux.intel.com>,
"Dr . David Alan Gilbert" <dgilbert@...hat.com>,
tony.luck@...el.com, marcorr@...gle.com,
sathyanarayanan.kuppuswamy@...ux.intel.com
Subject: Re: [PATCH v8 27/40] x86/boot: Add Confidential Computing type to
setup_data
On 12/13/21 6:49 AM, Brijesh Singh wrote:
>> I was more concerned that this structure could change sizes if it were
>> compiled on 32-bit versus 64-bit code. For kernel ABIs, we try not to
>> do that.
>>
>> Is this somehow OK when talking to firmware? Or can a 32-bit OS and
>> 64-bit firmware never interact?
>
> For SNP, both the firmware and OS need to be 64-bit. IIRC, both the
> Linux and OVMF do not enable the memory encryption for the 32-bit.
Could you please make the structure's size invariant? That's great if
there's no problem in today's implementation, but it's best no to leave
little land mines like this around. Let's say someone copies your code
as an example of something that interacts with a firmware table a few
years or months down the road.
Powered by blists - more mailing lists