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=-14.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no 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 3F82CC07E9B for ; Wed, 21 Jul 2021 07:17:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23ED860232 for ; Wed, 21 Jul 2021 07:17:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234599AbhGUGhE (ORCPT ); Wed, 21 Jul 2021 02:37:04 -0400 Received: from linux.microsoft.com ([13.77.154.182]:40348 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234267AbhGUGc3 (ORCPT ); Wed, 21 Jul 2021 02:32:29 -0400 Received: from [192.168.1.96] (unknown [223.226.82.147]) by linux.microsoft.com (Postfix) with ESMTPSA id 6E7CB20B7178; Wed, 21 Jul 2021 00:12:56 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6E7CB20B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1626851581; bh=MO7guIxHpjUQocmNc1KOQe8WT2YeXONIF9Q39UtiGI4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jy3C9M7d1CI71cZ2Gp4zrWil21i8NFLW0u5gL4HPqrXf6tGM/ev32wYNrUB+EH75u EHtEwieBOuPlIHfEuvptBtOrIAdyDou36L4pBUKaiAwsQNCBTixTAd6JaZOHtYrDKP X8qC9CLOne2eZF5ixqtKwauh6CEile+33Q/zxLa8= Subject: Re: [PATCH] hyperv: root partition faults writing to VP ASSIST MSR PAGE To: Michael Kelley , Wei Liu Cc: "linux-hyperv@vger.kernel.org" , "linux-kernel@vger.kernel.org" , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Dexuan Cui , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "x86@kernel.org" , "hpa@zytor.com" , "viremana@linux.microsoft.com" , Sunil Muthuswamy , "nunodasneves@linux.microsoft.com" References: <20210719185126.3740-1-kumarpraveen@linux.microsoft.com> <20210720112011.7nxhiy6iyz4gz3j5@liuwe-devbox-debian-v2> <20210720133514.lurmus2lgffcldnq@liuwe-devbox-debian-v2> <20210720162923.rsbl24v5lujbiddj@liuwe-devbox-debian-v2> From: Praveen Kumar Message-ID: Date: Wed, 21 Jul 2021 12:42:52 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21-07-2021 09:40, Michael Kelley wrote: > From: Wei Liu Sent: Tuesday, July 20, 2021 9:29 AM >> >> On Tue, Jul 20, 2021 at 04:20:44PM +0000, Michael Kelley wrote: >>> From: Wei Liu Sent: Tuesday, July 20, 2021 6:35 AM >>>> >>>> On Tue, Jul 20, 2021 at 06:55:56PM +0530, Praveen Kumar wrote: >>>> [...] >>>>>> >>>>>>> + if (hv_root_partition && >>>>>>> + ms_hyperv.features & HV_MSR_APIC_ACCESS_AVAILABLE) { >>>>>> >>>>>> Is HV_MSR_APIC_ACCESS_AVAILABLE a root only flag? Shouldn't non-root >>>>>> kernel check this too? >>>>> >>>>> Yes, you are right. Will update this in v2. thanks. >>>> >>>> Please split adding this check to its own patch. >>>> >>>> Ideally one patch only does one thing. >>>> >>>> Wei. >>>> >>> >>> I was just looking around in the Hyper-V TLFS, and I didn't see >>> anywhere that the ability to set up a VP Assist page is dependent >>> on HV_MSR_APIC_ACCESS_AVAILABLE. Or did I just miss it? >> >> The feature bit Praveen used is wrong and should be fixed. >> >> Per internal discussion this is gated by the AccessIntrCtrlRegs bit. >> >> Wei. >> > > The AccessIntrCtrlRegs bit *is* HV_MSR_APIC_ACCESS_AVAILABLE. > Both are defined as bit 4 of the Partition Privilege flags. :-) I don't > know why the names don't line up. Even so, it's not clear to me that > AccessIntrCtrlRegs has any bearing on the VP Assist page. I see this > description of AccessIntrCtrlRegs: > Yup, what I understood as well, this is the one required one for Partition Privilege Flags (4th bit), however, cannot comment on the naming convention. 5 /* Virtual APIC assist and VP assist page registers available */ 4 #define HV_MSR_APIC_ACCESS_AVAILABLE BIT(4) > The partition has access to the synthetic MSRs associated with the > APIC (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR). > If this flag is cleared, accesses to these MSRs results in a #GP fault if > the MSR intercept is not installed. > As per what I also understood from the TLFS doc,that we let partition access the MSR and do a fault. However, the point is, does it make sense to allocate page for vp assist and perform action which is meant to fail when the flag is cleared ? > But maybe you have additional info that applies to the root > partition that is not in the TLFS. > As per what discussed internally and I understood, the root partition shares the vp assist page provided by hypervisor and its read only for Root kernel. > Michael > Regards, ~Praveen.