From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Thu, 19 Aug 2021 10:52:53 +0100 From: Christoph Hellwig Subject: Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has() Message-ID: References: <7d55bac0cf2e73f53816bce3a3097877ed9663f3.1628873970.git.thomas.lendacky@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7d55bac0cf2e73f53816bce3a3097877ed9663f3.1628873970.git.thomas.lendacky@amd.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Tom Lendacky Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, iommu@lists.linux-foundation.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-graphics-maintainer@vmware.com, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, Borislav Petkov , Brijesh Singh , Joerg Roedel , Andi Kleen , Sathyanarayanan Kuppuswamy , Tianyu Lan , Thomas Gleixner , Ingo Molnar , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Joerg Roedel On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote: > While the name suggests this is intended mainly for guests, it will > also be used for host memory encryption checks in place of sme_active(). Which suggest that the name is not good to start with. Maybe protected hardware, system or platform might be a better choice? > +static inline bool prot_guest_has(unsigned int attr) > +{ > +#ifdef CONFIG_AMD_MEM_ENCRYPT > + if (sme_me_mask) > + return amd_prot_guest_has(attr); > +#endif > + > + return false; > +} Shouldn't this be entirely out of line? > +/* 0x800 - 0x8ff reserved for AMD */ > +#define PATTR_SME 0x800 > +#define PATTR_SEV 0x801 > +#define PATTR_SEV_ES 0x802 Why do we need reservations for a purely in-kernel namespace? And why are you overoading a brand new generic API with weird details of a specific implementation like this? _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec