[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220719215534.obolreae5dxdk223@black.fi.intel.com>
Date: Wed, 20 Jul 2022 00:55:34 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@...ux.intel.com>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
Kai Huang <kai.huang@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H . Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
Wander Lairson Costa <wander@...hat.com>,
Isaku Yamahata <isaku.yamahata@...il.com>,
marcelo.cerri@...onical.com, tim.gardner@...onical.com,
khalid.elmously@...onical.com, philip.cox@...onical.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 4/5] x86/mm: Add noalias variants of
set_memory_*crypted() functions
On Tue, Jul 19, 2022 at 10:10:20AM -0700, Sathyanarayanan Kuppuswamy wrote:
> >> +static struct shmem_priv intel_shmem = {
> >> + .init = intel_shmem_init,
> >> + .alloc = intel_shmem_alloc,
> >> + .free = intel_shmem_free,
> >> +};
> >
> > Hm. What is Intel-specific here. Looks like a generic thing, no?
> >
> > Maybe just drop all vendor stuff. CC_ATTR_MEM_ENCRYPT should be enough.
>
> I thought that not all CC vendors would want to use DMA APIs for shared
> buffer allocation. So adding a vendor layer would give them a way to implement
> their own model.
set_memory_decrypted() is gated by CC_ATTR_MEM_ENCRYPT and it is the only
requirement for functionality AFAICS.
--
Kirill A. Shutemov
Powered by blists - more mailing lists