Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Message-ID: <22921663-0e5e-58c0-c6c8-c45f991790ea@suse.com>
Date:   Thu, 21 Sep 2023 12:48:17 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Content-Language: en-US
To:     Xin Li <xin3.li@intel.com>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
        linux-hyperv@vger.kernel.org, kvm@vger.kernel.org,
        xen-devel@lists.xenproject.org
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        luto@kernel.org, pbonzini@redhat.com, seanjc@google.com,
        peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com,
        mhiramat@kernel.org, andrew.cooper3@citrix.com,
        jiangshanlai@gmail.com
References: <20230914044805.301390-1-xin3.li@intel.com>
 <20230914044805.301390-29-xin3.li@intel.com>
From:   Nikolay Borisov <nik.borisov@suse.com>
Subject: Re: [PATCH v10 28/38] x86/fred: FRED entry/exit and dispatch code
In-Reply-To: <20230914044805.301390-29-xin3.li@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y2JnV01GSm5Zb1dvbGQ3Q3FrWUhWV1lOeThvSUNmM1dsMUVqbVhVRDZaaWdl?=
 =?utf-8?B?MjhhYWVJNjV0RXRtT3VZc1p1WFN5RWdRWStPL01laDFQZlY2MHAyemozU2Fa?=
 =?utf-8?B?L0w2anJMZERzbWNSQkZyaVp6V3Jxd3VLVVFoYlk5QWVTcWF6MmNFR2xVckR2?=
 =?utf-8?B?Zitvc0NGQnpVc0NSZmdQbXMvcEpWb0tmQy9ZRDZObFJWeGwvcHFBM21QQ00z?=
 =?utf-8?B?aWFaU3JoTEdhVGJpMnBvbFhrcEIwczhGcDhyN0lVa1Nhajk0YmprK0ZzYVNW?=
 =?utf-8?B?aS9uS0tmcXZGK1VlV1FqcWZ2MEoyUVdxZFNPcHlKV3FZLzl6djl5V21pYWZt?=
 =?utf-8?B?a2tSZGRQMFEvLy9MQUl4bXRuUU1saGFta1daNU5FMGJsMDhoMHhPUlc3N0w0?=
 =?utf-8?B?R0ZPeEtLR2pzek53Z2s1WlJvM1Ara3B4Q0g1OVdOQ3VqeFp4MW96SmZjNDR3?=
 =?utf-8?B?NE1xeFN6czM1Q1ZkMnBGQWRnZDlTd3h0QmJmSGJCWnluZDNwSjhabVpWaStV?=
 =?utf-8?B?bm1XZkNXU0k2aDFPcDNLRmowa3psempVMVJvTlJUOGs2T2RoVjdGaG1rdzFI?=
 =?utf-8?B?dW1waTZuczFJaFRUUjcvWkpCWnBqOHpFREtNOVpFTk05QVIxRHVQczFGUnNK?=
 =?utf-8?B?a2RpMklvOHF2VDE1aXZJb3JKY2FqSUN0cnZtR3J4SkJGU0VnYWU1WmpyTmYv?=
 =?utf-8?B?QWY2UE5GZDZHQ01ydFkzR0E0UDQ4UzQybFdSM1V0Qjl5T3JIMGM1VkNERWp4?=
 =?utf-8?B?NXFrTklDUjloZUJpMlpyY0ppTVhpTFYxS3BmUXVHVHV6ZUI1cmNDNiswQXpT?=
 =?utf-8?B?L3hDSUtUMGs4TzNPenNLSk55QmFTZllBTWhCTzU1SW90ejVpeE1ZbTNQTzN1?=
 =?utf-8?B?aHU0RmZXejFwNHdObnBDSzdXTnVUN1NyZUsrOEo5NzBsTm43WDVocE5URnc2?=
 =?utf-8?B?Z1pmcnlML0t3R2ErNXU2VFdUT1JqNUNYOUVZbXJSc0Qzb1o1cWQrMFcvelE0?=
 =?utf-8?B?RjlMbHd5WlV1SHVhMWN0NjRkdVB6UE8renJ1Yk1veDRQODR3V3ZNR0Rxa2Q3?=
 =?utf-8?B?K3VYSENvMm8zclVoME53Q21lU1lVWW9jaE1GNThOQUZ3M0ZPQ1Q1VjFIM2tr?=
 =?utf-8?B?cVl1dEhPOWcvU25oblQ3SER2QXlRZDVFY1EwMDBVNmF0V2paNjF6cm9sNnZ2?=
 =?utf-8?B?aXluakw1WUJGd0RrVnM0WjBhWmhaRzRCaWxGK1BmZDAzV1pzUGhnVExZcGZk?=
 =?utf-8?B?dng0c1J0VmZSRU83N0QwTGFuaWsvMlZmNHlaK3lQTjVaZGU0YTcrS1VaNXRo?=
 =?utf-8?B?SE5UQ3RRMnJwREVid1VuY0grdnVkbXdOOHNOeW5DK0RIaCthVWt3Ym8zbjlL?=
 =?utf-8?B?ajVmSzFOTG1xcVN5RStkQ1dmVTl6VmlYRFpQYTZ2dVRXL3dUTXF2VCsrbVRM?=
 =?utf-8?B?TVlVUWcvRXl2TjI2RTJzaGhMK2g3cllvcVRxcHEyc25QRzg1dnlkeWVuOG90?=
 =?utf-8?B?anFTQTdXVFpsdDNPWi9nNGQ4QkxiL1Z4YXVGdUgwK2dTaWU2cnlaVENLcHVw?=
 =?utf-8?B?K1dtd3Rrb2pQbTNLcGJ2QkN3ZzB2cXdUTDZLWCtVSTVIMG1PU3RpK0VycVBr?=
 =?utf-8?B?a24xSFl1M3lqWUZjbTNFT0VscFpIZ2lQVUUvbVIzalo3VWZIR1NtVXhvdThQ?=
 =?utf-8?B?NmhtVnZzOG43VldQNHJzbkhHQmQwMm1tTENYUmpjb2diTXk5ZzZZWnVSME1r?=
 =?utf-8?B?TUc5QmdYcklDUFNTYVlBM3VsdHFNUldmTElaL3V0MzRpNUdSSU1JRFh3N1Zl?=
 =?utf-8?B?R2lkdFRPdERhaWhzQzBsYTdGV3AvTURBeWdIb3FjUDRCUFNDOVZzcUpHb3hS?=
 =?utf-8?B?bFJHU0NqZXkzZWd6cHc2WTlnQjZESlZlYVA4NXBKcHNpcDJiQWU2NEZOaWRP?=
 =?utf-8?B?dk1ydk1rQ29ubmhkeGxGbkRtWmRxczdKOHU0TzJCc3gwRXlzek1DNmIxaHlB?=
 =?utf-8?B?Z2RsYXVUdVFFWWIyL1huSG5EZWhud1VYekhWdjBIdzVNRW9rci82NzhNY2xH?=
 =?utf-8?B?bFRNMFhaZlYzVk42akRoZTB4OVcvcWNrdVNoOEpPbVRGd2ViVDRDSnRoQkk4?=
 =?utf-8?Q?MCItzrkc8EjMAQoSeb188ZAIV?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b1b8fa2-cbbb-4088-1fd6-08dbba87e39a
X-MS-Exchange-CrossTenant-AuthSource: PA4PR04MB7790.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2023 09:48:20.6861
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tfHyb3jA4LxAPzHm6Ad2rv1ExUj8mdshAfWKSYyD60NtpHZTrRXvvnzMsEf1JtcdG4UChwFSElA1TxfQEDXQgA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB8372
X-Spam-Status: No, score=-2.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
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 (agentk.vger.email [0.0.0.0]); Thu, 21 Sep 2023 14:08:38 -0700 (PDT)


On 14.09.23 г. 7:47 ч., Xin Li wrote:
> From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
> 
> The code to actually handle kernel and event entry/exit using
> FRED. It is split up into two files thus:
> 
> - entry_64_fred.S contains the actual entrypoints and exit code, and
>    saves and restores registers.
> - entry_fred.c contains the two-level event dispatch code for FRED.
>    The first-level dispatch is on the event type, and the second-level
>    is on the event vector.
> 
> Originally-by: Megha Dey <megha.dey@intel.com>
> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> Co-developed-by: Xin Li <xin3.li@intel.com>
> Tested-by: Shan Kang <shan.kang@intel.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Xin Li <xin3.li@intel.com>
> ---
> 
> Changes since v9:
> * Don't use jump tables, indirect jumps are expensive (Thomas Gleixner).
> * Except NMI/#DB/#MCE, FRED really can share the exception handlers
>    with IDT (Thomas Gleixner).
> * Avoid the sysvec_* idt_entry muck, do it at a central place, reuse code
>    instead of blindly copying it, which breaks the performance optimized
>    sysvec entries like reschedule_ipi (Thomas Gleixner).
> * Add asm_ prefix to FRED asm entry points (Thomas Gleixner).
> 
> Changes since v8:
> * Don't do syscall early out in fred_entry_from_user() before there are
>    proper performance numbers and justifications (Thomas Gleixner).
> * Add the control exception handler to the FRED exception handler table
>    (Thomas Gleixner).
> * Add ENDBR to the FRED_ENTER asm macro.
> * Reflect the FRED spec 5.0 change that ERETS and ERETU add 8 to %rsp
>    before popping the return context from the stack.
> 
> Changes since v1:
> * Initialize a FRED exception handler to fred_bad_event() instead of NULL
>    if no FRED handler defined for an exception vector (Peter Zijlstra).
> * Push calling irqentry_{enter,exit}() and instrumentation_{begin,end}()
>    down into individual FRED exception handlers, instead of in the dispatch
>    framework (Peter Zijlstra).
> ---
>   arch/x86/entry/Makefile               |   5 +-
>   arch/x86/entry/entry_64_fred.S        |  52 ++++++
>   arch/x86/entry/entry_fred.c           | 230 ++++++++++++++++++++++++++
>   arch/x86/include/asm/asm-prototypes.h |   1 +
>   arch/x86/include/asm/fred.h           |   6 +
>   5 files changed, 293 insertions(+), 1 deletion(-)
>   create mode 100644 arch/x86/entry/entry_64_fred.S
>   create mode 100644 arch/x86/entry/entry_fred.c
>


<snip>

> +
> +static noinstr void fred_intx(struct pt_regs *regs)
> +{
> +	switch (regs->fred_ss.vector) {
> +	/* INT0 */
> +	case X86_TRAP_OF:
> +		exc_overflow(regs);
> +		return;
> +
> +	/* INT3 */
> +	case X86_TRAP_BP:
> +		exc_int3(regs);
> +		return;
> +
> +	/* INT80 */
> +	case IA32_SYSCALL_VECTOR:
> +		if (likely(IS_ENABLED(CONFIG_IA32_EMULATION))) {

Since future kernels will support boottime toggling of whether 32bit 
syscall interface should be enabled or not as per:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/entry&id=1da5c9bc119d3a749b519596b93f9b2667e93c4a

It will make more sense to replace this with ia32_enabled() invocation. 
I guess this could be done as a follow-up patch based on when this is 
merged as the ia32_enbaled changes are going to be merged in 6.7.


> +			/* Save the syscall number */
> +			regs->orig_ax = regs->ax;
> +			regs->ax = -ENOSYS;
> +			do_int80_syscall_32(regs);
> +			return;
> +		}
> +		fallthrough;
> +
> +	default:
> +		exc_general_protection(regs, 0);
> +		return;
> +	}
> +}
> +
> +static __always_inline void fred_other(struct pt_regs *regs)
> +{
> +	/* The compiler can fold these conditions into a single test */
> +	if (likely(regs->fred_ss.vector == FRED_SYSCALL && regs->fred_ss.lm)) {
> +		regs->orig_ax = regs->ax;
> +		regs->ax = -ENOSYS;
> +		do_syscall_64(regs, regs->orig_ax);
> +		return;
> +	} else if (likely(IS_ENABLED(CONFIG_IA32_EMULATION) &&

Ditto

> +			  regs->fred_ss.vector == FRED_SYSENTER &&
> +			  !regs->fred_ss.lm)) {
> +		regs->orig_ax = regs->ax;
> +		regs->ax = -ENOSYS;
> +		do_fast_syscall_32(regs);
> +		return;
> +	} else {
> +		exc_invalid_op(regs);
> +		return;
> +	}
> +}
> +

<snip>