From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [RFC PATCH v4 11/28] x86: Add support to determine the E820 type of an address Date: Mon, 20 Feb 2017 21:09:55 +0100 Message-ID: <20170220200955.32e2wqxgulswnr55@pd.tnic> References: <20170216154158.19244.66630.stgit@tlendack-t1.amdoffice.net> <20170216154430.19244.95519.stgit@tlendack-t1.amdoffice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170216154430.19244.95519.stgit-qCXWGYdRb2BnqfbPTmsdiZQ+2ll4COg0XqFh9Ls21Oc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Tom Lendacky Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Brijesh Singh , Toshimitsu Kani , Radim =?utf-8?B?S3LEjW3DocWZ?= , Matt Fleming , x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Alexander Potapenko , "H. Peter Anvin" , Larry Woodman , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jonathan Corbet , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Ingo Molnar , Andrey Ryabinin , Rik van Riel , Arnd Bergmann , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, "Michael S. Tsirkin" , Paolo Bonzini List-Id: linux-mm.kvack.org On Thu, Feb 16, 2017 at 09:44:30AM -0600, Tom Lendacky wrote: > This patch adds support to return the E820 type associated with an address s/This patch adds/Add/ > range. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/e820/api.h | 2 ++ > arch/x86/include/asm/e820/types.h | 2 ++ > arch/x86/kernel/e820.c | 26 +++++++++++++++++++++++--- > 3 files changed, 27 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h > index 8e0f8b8..7c1bdc9 100644 > --- a/arch/x86/include/asm/e820/api.h > +++ b/arch/x86/include/asm/e820/api.h > @@ -38,6 +38,8 @@ > extern void e820__reallocate_tables(void); > extern void e820__register_nosave_regions(unsigned long limit_pfn); > > +extern enum e820_type e820__get_entry_type(u64 start, u64 end); > + > /* > * Returns true iff the specified range [start,end) is completely contained inside > * the ISA region. > diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/types.h > index 4adeed0..bf49591 100644 > --- a/arch/x86/include/asm/e820/types.h > +++ b/arch/x86/include/asm/e820/types.h > @@ -7,6 +7,8 @@ > * These are the E820 types known to the kernel: > */ > enum e820_type { > + E820_TYPE_INVALID = 0, > + Now this is strange - ACPI spec doesn't explicitly say that range type 0 is invalid. Am I looking at the wrong place? "Table 15-312 Address Range Types12" in ACPI spec 6. If 0 is really the invalid entry, then e820_print_type() needs updating too. And then the invalid-entry-add should be a separate patch. > E820_TYPE_RAM = 1, > E820_TYPE_RESERVED = 2, > E820_TYPE_ACPI = 3, -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.