Message ID | 20230914063325.85503-3-weijiang.yang@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp743493vqi; Thu, 14 Sep 2023 18:50:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG8MH9R9nyWgX9x+vifXb6fhRu15gySBfYkmUazOaGQi5qymvhPzD3txIkEYWCciIs9Y8nu X-Received: by 2002:a05:6a20:6a1a:b0:137:a08b:8bef with SMTP id p26-20020a056a206a1a00b00137a08b8befmr502536pzk.44.1694742655786; Thu, 14 Sep 2023 18:50:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694742655; cv=none; d=google.com; s=arc-20160816; b=A+GByDQFQWroe/AzVYfB33hcdmZqj4LDVdQchmLB6wD5rNI9BiqgWSJ/sM0sUEhy+c feZxqqS3/GUnGU2fd1xzClDP1cz17wJXjfLfK9zaqUBCYRetujZsQSvDYFoPdSm1iIlW HCSJQypTm3Uwrug/I10cgDM8gvksnKTPLsgR20sGfigK2o498OBlfqdy09+2Kqx122SE cuyDx6rXauq/BGFynxzoMHAWKQKPuhdqllJgMNlzHHRyWxkzVYl6F0cMEdbr9zdhLpF5 rbxgzCKKmmy4gwXVxkhFQt7MZBkqPOOrGEP0UrNhU1tD6OZXFGKlwhGWmp8fJb5Ng/eP LrPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=iwiP92oyn2ceCRI1LOdxG4MZKS9G4C55pN90o87BauE=; fh=jQqUhNQZPAXcZ44u72Wu3jv2pQizzn2Be2T8mkd1RwU=; b=hKK6n8D/Gj2Mee9+KakUZzq0JDGE2GhEPL8uuzSJkfRjDS8GFvIdgXLNlloyrV+5tK 0njCBce9uy8aeigGyIuy/oXOnlCx9ZVTDZ3y62+QXLwiKAEPGq6ct2mpYq6OiMdBs5aG Ue4pWsOecTtpXAJFGqWU1tfzYIVrq1eTsPRxaMv6kOHlr7c3aRAdiWlkx4NkRGD/MN1S qV2zG8/V5uqqNYwUPAKQbRFXqMHp7Ftd5wKnwGLwkRhvwg6YalL8hCGtnk0P8+h/89qL 97vjw1wwIg1UZU3uqTXAIeJStrEqr/msjQscer+6viUqi2oCHbIDVhKG/x7eBprsoaAJ YdLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cDIdwRKu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id s17-20020a170903201100b001c3976e2307si2382529pla.502.2023.09.14.18.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 18:50:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cDIdwRKu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 6EA778239DF5; Thu, 14 Sep 2023 02:38:29 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237303AbjINJi2 (ORCPT <rfc822;chrisfriedt@gmail.com> + 35 others); Thu, 14 Sep 2023 05:38:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235604AbjINJiU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Sep 2023 05:38:20 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 769FB83; Thu, 14 Sep 2023 02:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694684296; x=1726220296; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GCpk9GKZRRCMIQFL0D0NzM82+1bNcf1kwTMzwzthcgA=; b=cDIdwRKuoPTGI/WjCaaxW/Olk3zhTefEYBrEPNYRlQZmO1e5XXntAdO9 gHXyXLX6rc1YCtV3lxQ3IiCvRiaYpZHA8R8/W516ufKvtDabcKJWo5pmy 7w/3RuhjH/JWG54Wj7qKuxLliNvQv1s/5DdxwOh1VZbOCq/QnaCx5CGEa sLKynkOMKRtX1SdkltkQowdEpZ4EDg+pzO1idyiJSdfoZaNucm5fNUxh1 TMYsIpcIa74EYC+riVLEfX+1ulBUTY+OBN0X5isXBOsxr4lGe03tr1/FR Zh+cwwTJgb0DIeKoJC/Rcly/cpfoI1dgmQB76OqzaTJ7Xq2DbkP/B9gBy Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="409857313" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="409857313" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2023 02:38:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="747656212" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="747656212" Received: from embargo.jf.intel.com ([10.165.9.183]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2023 02:38:15 -0700 From: Yang Weijiang <weijiang.yang@intel.com> To: seanjc@google.com, pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: dave.hansen@intel.com, peterz@infradead.org, chao.gao@intel.com, rick.p.edgecombe@intel.com, weijiang.yang@intel.com, john.allen@amd.com Subject: [PATCH v6 02/25] x86/fpu/xstate: Fix guest fpstate allocation size calculation Date: Thu, 14 Sep 2023 02:33:02 -0400 Message-Id: <20230914063325.85503-3-weijiang.yang@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20230914063325.85503-1-weijiang.yang@intel.com> References: <20230914063325.85503-1-weijiang.yang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 14 Sep 2023 02:38:29 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777058939819866230 X-GMAIL-MSGID: 1777066475192191688 |
Series |
Enable CET Virtualization
|
|
Commit Message
Yang, Weijiang
Sept. 14, 2023, 6:33 a.m. UTC
Fix guest xsave area allocation size from fpu_user_cfg.default_size to
fpu_kernel_cfg.default_size so that the xsave area size is consistent
with fpstate->size set in __fpstate_reset().
With the fix, guest fpstate size is sufficient for KVM supported guest
xfeatures.
Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
---
arch/x86/kernel/fpu/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Comments
On 9/15/2023 6:45 AM, Edgecombe, Rick P wrote: > On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote: >> Fix guest xsave area allocation size from fpu_user_cfg.default_size >> to >> fpu_kernel_cfg.default_size so that the xsave area size is consistent >> with fpstate->size set in __fpstate_reset(). >> >> With the fix, guest fpstate size is sufficient for KVM supported >> guest >> xfeatures. >> >> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> > There is no fix (Fixes: ...) here, right? Ooh, I got it lost during rebase, thanks! > I think this change is needed > to make sure KVM guests can support supervisor features. But KVM CET > support (to follow in future patches) will be the first one, right? Exactly, the existing code takes only user xfeatures into account, and we have more and more CPU features rely on supervisor xstates. > The side effect will be that KVM guest FPUs now get guaranteed room for > PASID as well as CET. I think I remember you mentioned that due to > alignment requirements, there shouldn't usually be any size change > though? Yes, IIUC the precondition is AMX feature is enabled for guest so that the CET supervisor state actually resides in the gap to next 64byte aligned address, so no actual size expansion. > It might be nice to add that in the log, if I'm remembering > correctly. Sure, thanks!
On Fri, 2023-09-15 at 10:45 +0800, Yang, Weijiang wrote: > On 9/15/2023 6:45 AM, Edgecombe, Rick P wrote: > > On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote: > > > Fix guest xsave area allocation size from > > > fpu_user_cfg.default_size > > > to > > > fpu_kernel_cfg.default_size so that the xsave area size is > > > consistent > > > with fpstate->size set in __fpstate_reset(). > > > > > > With the fix, guest fpstate size is sufficient for KVM supported > > > guest > > > xfeatures. > > > > > > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> > > There is no fix (Fixes: ...) here, right? > > Ooh, I got it lost during rebase, thanks! > > > I think this change is needed > > to make sure KVM guests can support supervisor features. But KVM > > CET > > support (to follow in future patches) will be the first one, right? > > Exactly, the existing code takes only user xfeatures into account, > and we have more > and more CPU features rely on supervisor xstates. If KVM is not using any supervisor features, then pre CET KVM support I think the current code is more correct.
On Thu, Sep 14, 2023, Yang Weijiang wrote: > Fix guest xsave area allocation size from fpu_user_cfg.default_size to > fpu_kernel_cfg.default_size so that the xsave area size is consistent > with fpstate->size set in __fpstate_reset(). > > With the fix, guest fpstate size is sufficient for KVM supported guest > xfeatures. > > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> > --- > arch/x86/kernel/fpu/core.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > index a86d37052a64..a42d8ad26ce6 100644 > --- a/arch/x86/kernel/fpu/core.c > +++ b/arch/x86/kernel/fpu/core.c > @@ -220,7 +220,9 @@ bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu) > struct fpstate *fpstate; > unsigned int size; > > - size = fpu_user_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64); > + size = fpu_kernel_cfg.default_size + > + ALIGN(offsetof(struct fpstate, regs), 64); Shouldn't all the other calculations in this function also switch to fpu_kernel_cfg? At the very least, this looks wrong when paired with the above: gfpu->uabi_size = sizeof(struct kvm_xsave); if (WARN_ON_ONCE(fpu_user_cfg.default_size > gfpu->uabi_size)) gfpu->uabi_size = fpu_user_cfg.default_size;
On 10/21/2023 8:39 AM, Sean Christopherson wrote: > On Thu, Sep 14, 2023, Yang Weijiang wrote: >> Fix guest xsave area allocation size from fpu_user_cfg.default_size to >> fpu_kernel_cfg.default_size so that the xsave area size is consistent >> with fpstate->size set in __fpstate_reset(). >> >> With the fix, guest fpstate size is sufficient for KVM supported guest >> xfeatures. >> >> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> >> --- >> arch/x86/kernel/fpu/core.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c >> index a86d37052a64..a42d8ad26ce6 100644 >> --- a/arch/x86/kernel/fpu/core.c >> +++ b/arch/x86/kernel/fpu/core.c >> @@ -220,7 +220,9 @@ bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu) >> struct fpstate *fpstate; >> unsigned int size; >> >> - size = fpu_user_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64); >> + size = fpu_kernel_cfg.default_size + >> + ALIGN(offsetof(struct fpstate, regs), 64); > Shouldn't all the other calculations in this function also switch to fpu_kernel_cfg? > At the very least, this looks wrong when paired with the above: > > gfpu->uabi_size = sizeof(struct kvm_xsave); > if (WARN_ON_ONCE(fpu_user_cfg.default_size > gfpu->uabi_size)) > gfpu->uabi_size = fpu_user_cfg.default_size; Hi, Sean, Not sure what's your concerns. From my understanding fpu_kernel_cfg.default_size should include all enabled xfeatures in host (XCR0 | XSS), this is also expected for supporting all guest enabled xfeatures. gfpu->uabi_size only includes enabled user xfeatures which are operated via KVM uABIs(KVM_GET_XSAVE/KVM_SET_XSAVE/KVM_GET_XSAVE2), so the two sizes are relatively independent since guest supervisor xfeatures are saved/restored via GET/SET_MSRS interfaces.
On Tue, Oct 24, 2023, Weijiang Yang wrote: > On 10/21/2023 8:39 AM, Sean Christopherson wrote: > > On Thu, Sep 14, 2023, Yang Weijiang wrote: > > > Fix guest xsave area allocation size from fpu_user_cfg.default_size to > > > fpu_kernel_cfg.default_size so that the xsave area size is consistent > > > with fpstate->size set in __fpstate_reset(). > > > > > > With the fix, guest fpstate size is sufficient for KVM supported guest > > > xfeatures. > > > > > > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> > > > --- > > > arch/x86/kernel/fpu/core.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > > > index a86d37052a64..a42d8ad26ce6 100644 > > > --- a/arch/x86/kernel/fpu/core.c > > > +++ b/arch/x86/kernel/fpu/core.c > > > @@ -220,7 +220,9 @@ bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu) > > > struct fpstate *fpstate; > > > unsigned int size; > > > - size = fpu_user_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64); > > > + size = fpu_kernel_cfg.default_size + > > > + ALIGN(offsetof(struct fpstate, regs), 64); > > Shouldn't all the other calculations in this function also switch to fpu_kernel_cfg? > > At the very least, this looks wrong when paired with the above: > > > > gfpu->uabi_size = sizeof(struct kvm_xsave); > > if (WARN_ON_ONCE(fpu_user_cfg.default_size > gfpu->uabi_size)) > > gfpu->uabi_size = fpu_user_cfg.default_size; > > Hi, Sean, > Not sure what's your concerns. > From my understanding fpu_kernel_cfg.default_size should include all enabled > xfeatures in host (XCR0 | XSS), this is also expected for supporting all > guest enabled xfeatures. gfpu->uabi_size only includes enabled user xfeatures > which are operated via KVM uABIs(KVM_GET_XSAVE/KVM_SET_XSAVE/KVM_GET_XSAVE2), > so the two sizes are relatively independent since guest supervisor xfeatures > are saved/restored via GET/SET_MSRS interfaces. Ah, right, I keep forgetting that KVM's ABI can't use XRSTOR because it forces the compacted format. This part still looks odd to me: gfpu->xfeatures = fpu_user_cfg.default_features; gfpu->perm = fpu_user_cfg.default_features; but I'm probably just not understanding something in the other patches changes yet.
On 10/25/2023 12:32 AM, Sean Christopherson wrote: > On Tue, Oct 24, 2023, Weijiang Yang wrote: >> On 10/21/2023 8:39 AM, Sean Christopherson wrote: >>> On Thu, Sep 14, 2023, Yang Weijiang wrote: >>>> Fix guest xsave area allocation size from fpu_user_cfg.default_size to >>>> fpu_kernel_cfg.default_size so that the xsave area size is consistent >>>> with fpstate->size set in __fpstate_reset(). >>>> >>>> With the fix, guest fpstate size is sufficient for KVM supported guest >>>> xfeatures. >>>> >>>> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> >>>> --- >>>> arch/x86/kernel/fpu/core.c | 4 +++- >>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c >>>> index a86d37052a64..a42d8ad26ce6 100644 >>>> --- a/arch/x86/kernel/fpu/core.c >>>> +++ b/arch/x86/kernel/fpu/core.c >>>> @@ -220,7 +220,9 @@ bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu) >>>> struct fpstate *fpstate; >>>> unsigned int size; >>>> - size = fpu_user_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64); >>>> + size = fpu_kernel_cfg.default_size + >>>> + ALIGN(offsetof(struct fpstate, regs), 64); >>> Shouldn't all the other calculations in this function also switch to fpu_kernel_cfg? >>> At the very least, this looks wrong when paired with the above: >>> >>> gfpu->uabi_size = sizeof(struct kvm_xsave); >>> if (WARN_ON_ONCE(fpu_user_cfg.default_size > gfpu->uabi_size)) >>> gfpu->uabi_size = fpu_user_cfg.default_size; >> Hi, Sean, >> Not sure what's your concerns. >> From my understanding fpu_kernel_cfg.default_size should include all enabled >> xfeatures in host (XCR0 | XSS), this is also expected for supporting all >> guest enabled xfeatures. gfpu->uabi_size only includes enabled user xfeatures >> which are operated via KVM uABIs(KVM_GET_XSAVE/KVM_SET_XSAVE/KVM_GET_XSAVE2), >> so the two sizes are relatively independent since guest supervisor xfeatures >> are saved/restored via GET/SET_MSRS interfaces. > Ah, right, I keep forgetting that KVM's ABI can't use XRSTOR because it forces > the compacted format. > > This part still looks odd to me: > > gfpu->xfeatures = fpu_user_cfg.default_features; > gfpu->perm = fpu_user_cfg.default_features; I guess when the kernel FPU code was overhauled, the supervisor xstates were not taken into account for guest supported xfeaures, so the first line looks reasonable until supervisor xfeatures are landing. And for the second line, per current design, the user mode can only control user xfeatures via arch_prctl() kernel uAPI, so it also makes sense to initialize perm with fpu_user_cfg.default_features too. But in this CET KVM series I'd like to expand the former to support all guest enabled xfeatures, i.e., both user and supervisor xfeaures, and keep the latter as-is since there seems no reason to allow userspace to alter supervisor xfeatures. > but I'm probably just not understanding something in the other patches changes yet.
On Tue, 2023-10-24 at 09:32 -0700, Sean Christopherson wrote: > On Tue, Oct 24, 2023, Weijiang Yang wrote: > > On 10/21/2023 8:39 AM, Sean Christopherson wrote: > > > On Thu, Sep 14, 2023, Yang Weijiang wrote: > > > > Fix guest xsave area allocation size from fpu_user_cfg.default_size to > > > > fpu_kernel_cfg.default_size so that the xsave area size is consistent > > > > with fpstate->size set in __fpstate_reset(). > > > > > > > > With the fix, guest fpstate size is sufficient for KVM supported guest > > > > xfeatures. > > > > > > > > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> > > > > --- > > > > arch/x86/kernel/fpu/core.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > > > > index a86d37052a64..a42d8ad26ce6 100644 > > > > --- a/arch/x86/kernel/fpu/core.c > > > > +++ b/arch/x86/kernel/fpu/core.c > > > > @@ -220,7 +220,9 @@ bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu) > > > > struct fpstate *fpstate; > > > > unsigned int size; > > > > - size = fpu_user_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64); > > > > + size = fpu_kernel_cfg.default_size + > > > > + ALIGN(offsetof(struct fpstate, regs), 64); > > > Shouldn't all the other calculations in this function also switch to fpu_kernel_cfg? > > > At the very least, this looks wrong when paired with the above: > > > > > > gfpu->uabi_size = sizeof(struct kvm_xsave); > > > if (WARN_ON_ONCE(fpu_user_cfg.default_size > gfpu->uabi_size)) > > > gfpu->uabi_size = fpu_user_cfg.default_size; > > > > Hi, Sean, > > Not sure what's your concerns. > > From my understanding fpu_kernel_cfg.default_size should include all enabled > > xfeatures in host (XCR0 | XSS), this is also expected for supporting all > > guest enabled xfeatures. gfpu->uabi_size only includes enabled user xfeatures > > which are operated via KVM uABIs(KVM_GET_XSAVE/KVM_SET_XSAVE/KVM_GET_XSAVE2), > > so the two sizes are relatively independent since guest supervisor xfeatures > > are saved/restored via GET/SET_MSRS interfaces. > > Ah, right, I keep forgetting that KVM's ABI can't use XRSTOR because it forces > the compacted format. > > This part still looks odd to me: > > gfpu->xfeatures = fpu_user_cfg.default_features; That should be indeed fpu_kernel_cfg.default_features. This variable is also currently hardly used, it only tracks which dynamic userspace features are enabled and KVM only uses it once (in fpu_enable_guest_xfd_features) > gfpu->perm = fpu_user_cfg.default_features; This variable I think is currently only set and never read. Note that current->group_leader->thread.fpu.guest_perm is actually initialized to fpu_kernel_cfg.default_features but the kernel components of it masked in the corresponding prctl (ARCH_GET_XCOMP_SUPP/ARCH_GET_XCOMP_GUEST_PERM/ARCH_REQ_XCOMP_GUEST_PERM). So I think that we also should use fpu_kernel_cfg.default_features here for the sake of not having uninitilized variable on 32 bit kernels, because the whole FPU permission thing I see is implemented for 64 bit kernels only. Or even better IMHO is to remove both variables and in fpu_enable_guest_xfd_features, just mask the xfeatures with the XFEATURE_MASK_USER_DYNAMIC instead. Best regards, Maxim Levitsky > > but I'm probably just not understanding something in the other patches changes yet. >
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index a86d37052a64..a42d8ad26ce6 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -220,7 +220,9 @@ bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu) struct fpstate *fpstate; unsigned int size; - size = fpu_user_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64); + size = fpu_kernel_cfg.default_size + + ALIGN(offsetof(struct fpstate, regs), 64); + fpstate = vzalloc(size); if (!fpstate) return false;