From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1C2BE3B4E9A for ; Tue, 31 Mar 2026 06:56:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774940214; cv=none; b=jodddK6Xfo2wpaUYEegjcnpV9JleVTCntu7dJSG3dVl4UA7JoXOj5YjBR3SWtugTEIA3iY73hB8zYzt90qkp+u8nUm/M3um5OKHN0C1y/JLXYjwZ2bsywCXgxq0m2CXzQgOaQwV74QWXbDF+uDp9RGf4scbHmkPpEZXL+Egr22I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774940214; c=relaxed/simple; bh=FCThR5UMTwX4guFBkXBOF+jOcjwf+R89bVMAUnfqe4g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rROJv3SnZbUXTALcudQs4hCJOah2yVS84IdXk6fzDShUipoOZ5hQG1Z/nSI5CINBtJ2+QgN/2uJ9TJqRqt3AmcM1aubS2DG7vP/MdwmPHvzLU6miDgw3k1Mik4tPAPP0QwQQvBZw5UiDzFBR3paAvmd7dCX2lLel3b7J0LBIthI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Yeb5M3/k; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yeb5M3/k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E73B1C19423; Tue, 31 Mar 2026 06:56:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774940213; bh=FCThR5UMTwX4guFBkXBOF+jOcjwf+R89bVMAUnfqe4g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Yeb5M3/k5evvE+lZt1RvVFnn6oYO153MCVknrdmB55cjJmvWoNHtcFqD2kZ8rjyoo 9mMokMTkNIpJK5dw96iyK78ekjevguEUAUldAQEiYd5TLrZCSTJbggnSBzga2ZIGmE gr4FZywv+PR17p4/YNpJMIfIiRYjDPQdRHcyiY7bNqOWjcbSuFIl/OS/bePq5ggfeG waTVz8cMMFOTVfKLGQqWr+00M+xoJhiNdcavDRtER5yCsn38fa3ApOHpUtic9y3cMy ww35Z6UQNrXTiH06smyAWILK7y7vWrdxUfqaIBPTDVBM6c8haqLm/C9f1+Y5yGfOLN t7II6Oj3VFBrw== Date: Tue, 31 Mar 2026 08:56:49 +0200 From: Ingo Molnar To: Uros Bizjak Cc: x86@kernel.org, linux-kernel@vger.kernel.org, "H. Peter Anvin" , Thomas Gleixner , Borislav Petkov , Dave Hansen Subject: Re: [PATCH 1/2] x86/segment: Introduce storesegment() helper to write segment selectors to memory Message-ID: References: <20260331063838.108857-1-ubizjak@gmail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260331063838.108857-1-ubizjak@gmail.com> * Uros Bizjak wrote: > Introduce a new helper, storesegment(), that stores a segment selector > directly into a u16 (or compatible) memory location without using an > intermediate general-purpose register. > > To support this, split the existing SAVE_SEGMENT macro into two parts: > > SAVE_SEGMENT_VAR(): retains the current behavior of reading a segment > register into an unsigned long via a register. > SAVE_SEGMENT_PTR(): adds a new variant that writes the 16-bit selector > directly to memory. > > The combined SAVE_SEGMENT() macro now generates both helpers for each > segment register. > > The new storesegment() interface is preferred over savesegment() when > the value only needs to be stored (e.g. into a struct field), avoiding > an unnecessary register move and making the intent clearer. > > No functional change for existing users of savesegment(). Why does the API have to be split into =r and =m variants? Coulnd't we use a more generic constraint and let the compiler decide what the target is? Would that negatively impact other aspects of code generation? Thanks, Ingo