From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34817C433E9 for ; Tue, 26 Jan 2021 15:25:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E85323109 for ; Tue, 26 Jan 2021 15:25:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389645AbhAZPZ1 (ORCPT ); Tue, 26 Jan 2021 10:25:27 -0500 Received: from mail-wr1-f48.google.com ([209.85.221.48]:35435 "EHLO mail-wr1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404621AbhAZPYr (ORCPT ); Tue, 26 Jan 2021 10:24:47 -0500 Received: by mail-wr1-f48.google.com with SMTP id l12so16885992wry.2; Tue, 26 Jan 2021 07:24:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PrVukTZfpBWrivFQx71zTzZ9+Nxp6Oo20gBZUehsy5s=; b=ZhFEKZhoHsRLqnYTE3mmkL1eDK+6wkvEniFxlT1IucXQLoXLwZmbIc+4FsOdljcdlA U7djDnxDJ5e+bWosXt0CSL1CnEOXFHkVW9qPujWcxmo2n5eSi2APZWiHQGRkM137eI35 NkRE3vUwRMyYyX925+yoEFf9OlfwL6w4yzw4sIlYbkPxlWzTOiW28/NVPaJJRu0SRNfZ aG1c8AbbHMyj001hoz7lKG+viJ6tVeuhsyQ/6NvGZ6jZKI2TsxhVodq46itV9WVHV8AX +GSYHTXHfRoN56RndMeIFFKoMFz3Ieq85+Ukt0yYprWzeA2XyueDoSdP8G9ODpgsLgTt HhKw== X-Gm-Message-State: AOAM531AUm+9c5hzIWjsVPPmSnYmsdJ5uxhcbwlOjdCL9LfxKQcGd9li IfQQVVbEVBi2tr4xz24rQ6s= X-Google-Smtp-Source: ABdhPJyiHQ3GQJRDGIeVA81E2ax1dSw7LkvxoYhVeCxBQ0oJbFBvU6SYZ/92UzPlHpF5prZAbNS00w== X-Received: by 2002:a5d:4402:: with SMTP id z2mr6659970wrq.265.1611674644833; Tue, 26 Jan 2021 07:24:04 -0800 (PST) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id u7sm15268845wrr.80.2021.01.26.07.24.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jan 2021 07:24:04 -0800 (PST) Date: Tue, 26 Jan 2021 15:24:03 +0000 From: Wei Liu To: Michael Kelley Cc: Wei Liu , Linux on Hyper-V List , "virtualization@lists.linux-foundation.org" , Linux Kernel List , Vineeth Pillai , Sunil Muthuswamy , Nuno Das Neves , "pasha.tatashin@soleen.com" , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" Subject: Re: [PATCH v5 02/16] x86/hyperv: detect if Linux is the root partition Message-ID: <20210126152403.5x5p5f5vb3lchqo6@liuwe-devbox-debian-v2> References: <20210120120058.29138-1-wei.liu@kernel.org> <20210120120058.29138-3-wei.liu@kernel.org> <20210126151512.jz4f3jxfs7ommvm3@liuwe-devbox-debian-v2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210126151512.jz4f3jxfs7ommvm3@liuwe-devbox-debian-v2> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Tue, Jan 26, 2021 at 03:15:12PM +0000, Wei Liu wrote: > On Tue, Jan 26, 2021 at 12:31:31AM +0000, Michael Kelley wrote: > > From: Wei Liu Sent: Wednesday, January 20, 2021 4:01 AM > > > > > > For now we can use the privilege flag to check. Stash the value to be > > > used later. > > > > > > Put in a bunch of defines for future use when we want to have more > > > fine-grained detection. > > > > > > Signed-off-by: Wei Liu > > > --- > > > v3: move hv_root_partition to mshyperv.c > > > --- > > > arch/x86/include/asm/hyperv-tlfs.h | 10 ++++++++++ > > > arch/x86/include/asm/mshyperv.h | 2 ++ > > > arch/x86/kernel/cpu/mshyperv.c | 20 ++++++++++++++++++++ > > > 3 files changed, 32 insertions(+) > > > > > > diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h > > > index 6bf42aed387e..204010350604 100644 > > > --- a/arch/x86/include/asm/hyperv-tlfs.h > > > +++ b/arch/x86/include/asm/hyperv-tlfs.h > > > @@ -21,6 +21,7 @@ > > > #define HYPERV_CPUID_FEATURES 0x40000003 > > > #define HYPERV_CPUID_ENLIGHTMENT_INFO 0x40000004 > > > #define HYPERV_CPUID_IMPLEMENT_LIMITS 0x40000005 > > > +#define HYPERV_CPUID_CPU_MANAGEMENT_FEATURES 0x40000007 > > > #define HYPERV_CPUID_NESTED_FEATURES 0x4000000A > > > > > > #define HYPERV_CPUID_VIRT_STACK_INTERFACE 0x40000081 > > > @@ -110,6 +111,15 @@ > > > /* Recommend using enlightened VMCS */ > > > #define HV_X64_ENLIGHTENED_VMCS_RECOMMENDED BIT(14) > > > > > > +/* > > > + * CPU management features identification. > > > + * These are HYPERV_CPUID_CPU_MANAGEMENT_FEATURES.EAX bits. > > > + */ > > > +#define HV_X64_START_LOGICAL_PROCESSOR BIT(0) > > > +#define HV_X64_CREATE_ROOT_VIRTUAL_PROCESSOR BIT(1) > > > +#define HV_X64_PERFORMANCE_COUNTER_SYNC BIT(2) > > > +#define HV_X64_RESERVED_IDENTITY_BIT BIT(31) > > > + > > > > I wonder if these bit definitions should go in the asm-generic part of > > hyperv-tlfs.h instead of the X64 specific part. They look very architecture > > neutral (in which case the X64 should be dropped from the name > > as well). Of course, they can be moved later when/if we get to that point > > and have a firmer understanding of what is and isn't arch neutral. > > Yes. This is the approach I'm taking here. They can be easily moved in > the future if there is a need. > > > > > > /* > > > * Virtual processor will never share a physical core with another virtual > > > * processor, except for virtual processors that are reported as sibling SMT > > > diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h > > > index ffc289992d1b..ac2b0d110f03 100644 > > > --- a/arch/x86/include/asm/mshyperv.h > > > +++ b/arch/x86/include/asm/mshyperv.h > > > @@ -237,6 +237,8 @@ int hyperv_fill_flush_guest_mapping_list( > > > struct hv_guest_mapping_flush_list *flush, > > > u64 start_gfn, u64 end_gfn); > > > > > > +extern bool hv_root_partition; > > > + > > > #ifdef CONFIG_X86_64 > > > void hv_apic_init(void); > > > void __init hv_init_spinlocks(void); > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > > index f628e3dc150f..c376d191a260 100644 > > > --- a/arch/x86/kernel/cpu/mshyperv.c > > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > > @@ -32,6 +32,10 @@ > > > #include > > > #include > > > > > > +/* Is Linux running as the root partition? */ > > > +bool hv_root_partition; > > > +EXPORT_SYMBOL_GPL(hv_root_partition); > > > + > > > struct ms_hyperv_info ms_hyperv; > > > EXPORT_SYMBOL_GPL(ms_hyperv); > > > > > > @@ -237,6 +241,22 @@ static void __init ms_hyperv_init_platform(void) > > > pr_debug("Hyper-V: max %u virtual processors, %u logical processors\n", > > > ms_hyperv.max_vp_index, ms_hyperv.max_lp_index); > > > > > > + /* > > > + * Check CPU management privilege. > > > + * > > > + * To mirror what Windows does we should extract CPU management > > > + * features and use the ReservedIdentityBit to detect if Linux is the > > > + * root partition. But that requires negotiating CPU management > > > + * interface (a process to be finalized). > > > + * > > > + * For now, use the privilege flag as the indicator for running as > > > + * root. > > > + */ > > > + if (cpuid_ebx(HYPERV_CPUID_FEATURES) & HV_CPU_MANAGEMENT) { > > > > Should the EBX value be captured in the ms_hyperv structure with the > > other similar values, and then used from there? > > > > There is only one usage of this in this whole series so I didn't bother > capturing. I would also like to clean up ms_hyperv_info's fields a bit. Correction: there are two patches that use this. But the rest of my argument stands. > > Given there are quite some patches pending which change ms_hyperv_info > struct, I would like to avoid creating more conflicts than necessary. > > My plan is to implement my idea from the thread "Field names inside > ms_hyperv_info" once all patches that touch ms_hyperv_info are merged. > > Wei.