From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A3BDA309EE7 for ; Fri, 5 Jun 2026 15:51:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780674692; cv=none; b=WEDmyPRCDdxwAmpuLUoeBtCS9MzuVVFTSLM0e4dnarWH1C6uMUe207bmZdXghXSYbrkvwVzPg8rbvaXwIuvDaXfKc12SlljXvXJFjPmccsOz+L79dsA1d6YxCiLBUKSgUCFJSeUFL4qBGpZ8UtrRjbPoFrEJADzsdEbREczsJ/U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780674692; c=relaxed/simple; bh=13ZnZoZ2ANijRiESp1RJI0AE/fgpzEpAkeaIabVD/2U=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=aHohCCi7bD5+n4yG3E4FgsUwagwnqCG9dordsT7SLGK21UCJBFS1ghdXLrcDMmEPefOIq+YBSsquwqXW+gkWH0faf4atOPYr4BMJnO7kxbhiLfdESmFLZ1O9LjE1IcpiygZWYbCeQgrfb92y7Fn5zLhRDMzezxCIqzXhEf3wBB8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=kMbkhjac; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="kMbkhjac" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 655FpA8Q1431304 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 5 Jun 2026 08:51:11 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 655FpA8Q1431304 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1780674671; bh=32hAIpGga4kyPb5idIz9kG+b6m6JcZNq81vlINhQUuU=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=kMbkhjac+kPq7opI5jU5smqfzytcPxkVToWZScfYji754crROR6UePWsxQOV54sMw 0G9ia98gmQVqNG/pWiFPq/OyrETlwxZjBAN062zye+JyZohLP8WKiJqkRZAghOuIM9 CliTcaKTzBP+Ycfh2ry1PaeE1q7ygsVd0TWvq4XvxZDcEYq3Fa+YdFpaJEZ+TjAHLT 82H3bQLiNQQk+jDxf5xIQAHjb/UmsVYQe9pPPSM4N1HlM0CquKiMIBs0RdCTSUUAks jcuTso0wyFYu7ysjHMgSVmin5wIKMbyaaUlEknuzbQJfEnX2qzlx/pSw07Ut2VnB/I JpZbNbDJJ3Ymw== Date: Fri, 05 Jun 2026 08:51:04 -0700 From: "H. Peter Anvin" To: Andrew Cooper , Borislav Petkov CC: x86-ML , LKML Subject: Re: Save a WRMSR GS.base? User-Agent: K-9 Mail for Android In-Reply-To: <2f297456-d6c6-4cc8-95d8-2dac6bea99ec@citrix.com> References: <20260604015303.GEaiDafyuU0bwP4Y05@fat_crate.local> <180aeb02-4ed9-436c-ba61-c8559eb7994c@citrix.com> <20260605022428.GBaiIzXL7TgIjMj8d7@fat_crate.local> <18B4FA09-40DE-43D0-A3D0-DD16DE652B87@zytor.com> <20260605025453.GAaiI6fdfradMwrUEk@fat_crate.local> <8820E259-DDAF-46F7-9800-F983D6BBE3DB@zytor.com> <20260605042652.GBaiJQDMRcO_lO0Gig@fat_crate.local> <20260605043846.GCaiJS1iXH8A6Cb3Vy@fat_crate.local> <0F905129-3447-4173-A88B-98EAC8C18E4C@zytor.com> <1E2599FB-0A39-4637-B042-EE36DA224264@zytor.com> <2f297456-d6c6-4cc8-95d8-2dac6bea99ec@citrix.com> Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On June 5, 2026 8:16:53 AM PDT, Andrew Cooper wrote: >On 05/06/2026 4:13 pm, H=2E Peter Anvin wrote: >> On June 5, 2026 2:13:07 AM PDT, Andrew Cooper wrote: >>> On 05/06/2026 6:05 am, H=2E Peter Anvin wrote: >>>> On June 4, 2026 9:38:46 PM PDT, Borislav Petkov wrot= e: >>>>> On Thu, Jun 04, 2026 at 09:30:33PM -0700, H=2E Peter Anvin wrote: >>>>>> On June 4, 2026 9:26:52 PM PDT, Borislav Petkov wr= ote: >>>>>>> On Thu, Jun 04, 2026 at 08:20:57PM -0700, H=2E Peter Anvin wrote: >>>>>>>> I guess the question is why there is a "first" one=2E >>>>>>> That happens when we do: >>>>>>> >>>>>>> x86_fsgsbase_load() >>>>>>> >>>>>>> loadseg(GS) -> load_gs_index() -> native_load_gs_index() -> >>>>>>> if (cpu_feature_enabled(X86_FEATURE_LKGS)) >>>>>>> native_lkgs(selector); >>>>>>> >>>>>>> then back in x86_fsgsbase_load() we do: >>>>>>> >>>>>>> __wrgsbase_inactive(next->gsbase); >>>>>>> >>>>>>> which does >>>>>>> >>>>>>> wrmsrq(MSR_KERNEL_GS_BASE, gsbase); >>>>>>> >>>>>>> on FRED=2E >>>>>>> >>>>>>> But LKGS already wrote MSR_KERNEL_GS_BASE=2E=2E=2E >>>>>>> >>>>>>>> Logically the sequence should be LKGS first, if needed; then WRMS= R(NS)=2E LKGS >>>>>>>> can be replaced with swapgs/mov gs/swapgs on legacy=2E >>>>>>> Right=2E >>>>>>> >>>>>>> I think avoiding that second WRMSR(MSR_KERNEL_GS_BASE) should give= some perf >>>>>>> back=2E=2E=2E >>>>>>> >>>>>>> Although, I need to think how to make it pretty=2E=2E=2E >>>>>>> >>>>>> Should be doing wrmsrns=2E=2E=2E >>>>> No, I think that second WRMSR* should not happen at all if we have e= xecuted >>>>> LKGS which has already written MSR_KERNEL_GS_BASE, right? >>>>> >>>>> >>>> You can't do that (at least not without further checks) if user space= has WRGSBASE enabled, since you have no guarantee that the active GS=2Ebas= e is consistent with GS=2Eselector=2E >>>> >>>> Since GS > 3 is pretty rare in 64-bit code at least, it doesn't seem = to be a code path that needs to be that heavily optimized=2E >>> I think you're slightly talking past each other, and I also made a >>> mistake on the original reply, so lets try rephrasing it=2E >>> >>> LGKS only writes a zero-extended 32bit value into KERN_GS_BASE=2E=C2= =A0 This is >>> because there's only 32 bits of information in the GDT/LDT=2E >>> >>> So the real write into KERN_GS_BASE is still needed=2E=C2=A0 Sorry - y= ou can't >>> optimise this away=2E=C2=A0 Also, I'm pretty sure amluto did some x86 = selftests >>> covering this last time the logic was rewritten=2E >>> >>> >>> As to WRMSR vs WRMSRNS, yes Intel CPUs want this to be WRMSRNS=2E=C2= =A0 AMD >>> don't have WRMSRNS but this particular MSR index is architecturally no= t >>> architecturally serialising anyway=2E >>> >>> ~Andrew >> It's not just a matter of it being a 32-bit base, it might not even be = the correct one even so=2E > >Indeed, GS might be an LDT selector=2E > >~Andrew No, GS=2Ebase might have been loaded (with wrgsbase) after GS was loaded, = so it could be *completely different*=2E