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 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7875E1061219 for ; Wed, 11 Mar 2026 11:06:58 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1251021.1548334 (Exim 4.92) (envelope-from ) id 1w0HOk-0007To-NI; Wed, 11 Mar 2026 11:06:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251021.1548334; Wed, 11 Mar 2026 11:06:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0HOk-0007Th-K7; Wed, 11 Mar 2026 11:06:42 +0000 Received: by outflank-mailman (input) for mailman id 1251021; Wed, 11 Mar 2026 11:06:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0HOj-0007Tb-VD for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 11:06:41 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 60a3ca31-1d3a-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 12:06:39 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so32414375e9.2 for ; Wed, 11 Mar 2026 04:06:39 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4854b66dedfsm45501465e9.12.2026.03.11.04.06.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 04:06:37 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60a3ca31-1d3a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773227199; x=1773831999; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=THWX4dw5nHbItcNRFe55nzEA85XRDepCbjCrxbTfMaE=; b=K1wpU7N4SChaJjavzN9OGVmCiZa6aKqJH+YM0eBNXZ9LKxiHFNWy7/hiMeVeGqt98b /xd4FzDPnZj8Ar+WXXPSLUsc/tmbD+9iQUm6zwaBDg20VTT/x3JACjDCjWiMmAHJhhJO 1WgM/P7pz/X0jxW7iEHfwPl+KPXfjwoYgggijQEAd+xkOieqd9VkaF4eTvNMZKb693qf EjWiWK0wAJzPtZsX7RAnMWY1DSgtxiCmH36Bh2xI2OIV85xYgAfio0OjYoOqBJcwovx5 eL5KfOplcusbHJk8o8om8qslPhkLeIBl1QEkPcN1BWKPmi6IO1DDHreNi99hhhYCPzkR cVmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773227199; x=1773831999; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=THWX4dw5nHbItcNRFe55nzEA85XRDepCbjCrxbTfMaE=; b=dB4y8vf0u9+IINE5dERNN94cBftKRF2IcUrd+g5QGMkpNglaE0Kygs91RanpOYfSox 5kIG7TGTjVegtfH97u3OLB94rPS6Hv0dsueG5qd8ByzIPapZGMHveo90TD4BxOcouSU+ pQfF5Zfhtg2TRCuXfqK18MwLo7okIkfLvA6heoAQNHXKnfEsi2N0NpadiyoGX4sq3EiG VdqCeD9r3Op49t/LGemrbA47DKozJNz4ZtiN7c8lPNWU8wTFEuFczGpU7iFj6wbuuiz+ 0FyJy8LXeErNYd9+2bstP+LAR7cKvi755EU7TpuD3KBVrqmiEgAt4rechHDjTmOkQKxX QUTQ== X-Forwarded-Encrypted: i=1; AJvYcCVrHkdKBS8EytQ5Cq7bnSBWyDZfJ0yc5Ldau1Sx0q69GwcoIjT9fON5U80pkh7VzgOIVlQmg5jX20U=@lists.xenproject.org X-Gm-Message-State: AOJu0YzvTbuvARkYefij5jhoQ/Y8+MrIwDYSG8RLnV7NV7MPQ9cnJbJx RkyVSgzBvqFb2KuDmHaKtn76SuNKrmtnSCkzeA1CNYZk77lxztl0kpmZ7FERHFtM0g== X-Gm-Gg: ATEYQzyetMfFEVRh7eP/SOk7De2vekkNVPbDX/nA5Mpi4oMu1O2E2ECnk20Wu2qbHGS Mb0iJRehPH8gAV8mb6aPDWBXQh70Mxal9iggVeq/mZZCFM7SUzgU2AWjI8pvHzXX8zHXPO4oHse Sn4Jpv0Wyf9LBitmMHX6UgQ6f/am26VGXuTGSMVElECC0AA+Lt/yjzt8TG30tu0HR5WKr9kg+C/ qCxSUmNYcV6qiQp5aShTw+jO2vsnwN3FIOJMh8OrGSvrrAs+eVicEGhKcD0Mh9ej+4Vu7Iqqz72 DMQvjZj6RhoeyiWpCRvW8+jkiKhXJc5mF5j+CPzVohFxNUrPiVKxqAXCvuGd77FZAlcX06b2R7H hHDVYJK5QK8KcPI00RTF8CcsTvLMhewR/NQMR6L9TT/zQkuEov1H2LeIhNF5BYVS01xyiq44nsW 5r8e8rVemSiAlFgORNt5CHNzNknLb1GuozqMMDUzqG7CysFs2TKtAc4d9EYrLXAQRnh7sK04atg s26sFnuYZtME0w= X-Received: by 2002:a05:600c:45c3:b0:485:3473:d4a1 with SMTP id 5b1f17b1804b1-4854b13e63emr36476885e9.34.1773227198440; Wed, 11 Mar 2026 04:06:38 -0700 (PDT) Message-ID: <66926b3b-82e0-4595-b54f-e73cef396ea2@suse.com> Date: Wed, 11 Mar 2026 12:06:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/4] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-3-alejandro.garciavallejo@amd.com> <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 11:21, Alejandro Vallejo wrote: > On Wed Mar 11, 2026 at 10:30 AM CET, Jan Beulich wrote: >> On 11.03.2026 10:25, Alejandro Vallejo wrote: >>> On Wed Mar 11, 2026 at 9:35 AM CET, Jan Beulich wrote: >>>> On 13.02.2026 12:42, Alejandro Vallejo wrote: >>>>> - if ( opt_hvm_fep ) >>>>> - { >>>>> - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; >>>>> - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) >>>>> - ? PFEC_user_mode : 0) | PFEC_insn_fetch; >>>> >>>> Why is this initializer not retained? >>> >>> It is, it's just that the diff is terrible. An unfortunate side effect of the >>> removal of the braces. The scope collapsing forces it on top of the function, >>> before the emulation context is initialised. >>> >>> It's set up in steps. walk is unconditionally initialised as isnsn_fetch, and >>> later (after emulate_init_once()), OR'd with PFEC_user_mode for DPL == 3. See... >>> >>>> >>>>> - unsigned long addr; >>>>> - char sig[5]; /* ud2; .ascii "xen" */ >>>>> - >>>>> - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, >>>>> - sizeof(sig), hvm_access_insn_fetch, >>>>> - cs, &addr) && >>>>> - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), >>>>> - walk, NULL) == HVMTRANS_okay) && >>>>> - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) >>>>> - { >>>>> - regs->rip += sizeof(sig); >>>>> - regs->eflags &= ~X86_EFLAGS_RF; >>>>> + hvm_emulate_init_once(&ctxt, NULL, regs); >>>>> >>>>> - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ >>>>> - if ( !(hvm_long_mode_active(cur) && cs->l) ) >>>>> - regs->rip = (uint32_t)regs->rip; >>>>> + if ( ctxt.seg_reg[x86_seg_ss].dpl == 3 ) >>>>> + walk |= PFEC_user_mode; >>> >>> ... here. >> >> But that's the point of my question: Why did you split it? All you mean to >> do is re-indentation. > > Because I need to declare "walk" ahead of the statements. Thus this... > > uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > ? PFEC_user_mode : 0) | PFEC_insn_fetch; > > must (by necessity) have the declaration placed on top before the emulator > context initialisation. The options are... > > uint32_t walk; > [... lines ...] > walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > ? PFEC_user_mode : 0) | PFEC_insn_fetch; > > ... or... > > uint32_t walk = PFEC_insn_fetch; > [... lines ...] > if ( ctxt.seg_reg[x86_seg_ss].dpl == 3 ) > walk |= PFEC_user_mode; > > Line count remains at 3 in both cases, but in the former case there's a > comparison, a ternary operator and an OR all adding cognitive load to the > same statement. In the latter case there's an assignment in the 1st statement, > an if+comparison in a separate line, and a separate OR in the final statement. > It's just simpler to meantally parse because the complexity is evenly > distributed. > > I can see how the current form was preferred to avoid a third line (and > then a forth due to the required newline, doubling the total). But with the > rearrangement that's no longer relevant. > > If you have a very strong preference for the prior form I could keep it, though > I do have a preference myself for the latter out of improved readability. Strong preference or not - readability is subjective. I prefer the present form, where the variable obtains it final value right away. More generally, with subjective aspects it may often be better to leave mechanical changes (here: re-indentation) as purely mechanical. Things are different with objective aspects, like style violations which of course can (and imo preferably should) be corrected on such occasions. Jan